Sunday, November 29, 2009

Where portability matters

What's a good example of a software solution where portability is a paramount design quality attribute? Tethering software for mobile phones. PDANet, an application developed by June Fabrics, is a good example where designing for portability is a top design concern.

Portability is defined as the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two. (Definition source)

PDANet enables PDA owners to convert their device into an Internet connection. It's hard to say if the talented folks at the June Fabrics initially planned to expand their PDANet software to other mobile OS vendors, but this application is a prime example where portability matters.

Currently PDANet supports Android, Palm OS, Windows Mobile, BlackBerry, and iPhone. While the operating systems are fundamentally different and provide different level of services to developers, the architectural drivers (i.e. architecturally significant requirements) and the general purpose of the devices is the same. Therefore the logical allocation of requirements to solution modules should be the same across all operating systems. However physical implementation would be different for each OS.

This is another great example where the benefits of software reuse come not from source code reuse, but from the reuse of software architecture artifacts.

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Saturday, November 28, 2009

Impact of organizational politics on software design

What is the impact of organizational politics on software design? This is a question I raised three years ago in this post and the time has finally come to attempt to answer that question.

We, as software solution stakeholders, make conscious and subconscious decisions that have a profound long-term effect on the usability, maintainability, cost, security, implementability, any-ility of a software solution. But how often are these decisions based on our personal and career motivations? Are we aware of this? Is it a good or a bad thing? If my career is centered around a certain vendor (e.g. Oracle and Java) should I or even can I viably consider technology from other vendors (e.g. SQL Server and .NET)? Would I have enough technical knowledge?

If you have an immediate thought on the impact of organizational politics on software design please leave a comment. And look for a formal invitation to fill out a survey in the very near future.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Friday, November 27, 2009

Essays by Paul Graham

Paul Graham is an essayist, programmer, and programming language designer. If you haven't read his essays on programming and software engineering you should consider.

His latest essay on Apple's iPhone store is a good read on how business models that work for product n may not work for a product y. In this case Apple is treating iPhone apps as if they were iTunes songs, and Apple being the broker between the consumer and software producer. The nature of the development process of the iPhone apps requires frequent, if not daily, iteration of software releases, while Apple favors a lengthy review cycle before an app is published in its stores. What will it take for the developers to switch platforms? When will Apple become the evil empire? You can find the latest essay here and the rest of the essays here.

Subscribe to this blog via RSS.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Pricing Software

We're in the business of software. That's why we all care, directly or indirectly about its pricing. Pricing affects everything - our salaries, benefits, profit. We also care about pricing because we're all are buyers of software (COTS, GOTS, development tools, etc.). And of course with respect to computer systems the cost of software exponentially outweighs the cost of hardware.

The new book, Don't Just Roll The Dice - A usefully short guide to software pricing, is a quick read, mere 84 pages, raises the right questions to get you thinking.

"How do you price your software? Is it art, science or magic? How much attention should you pay to your competitors? This short handbook will provide you with the theory, practical advice and case studies you need to stop yourself from reaching for the dice." Download a free copy here or get an a physical copy from Amazon.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Sunday, November 22, 2009

Software engineers are also your solution architecture stakeholders

It's easy to forget that the software engineers on your development team are also your stakeholders. They need a particular view of solution architecture in order to understand how they fit into the development ecosystem.

Expect to be challenged. As you walk through your vision or proposal for how a solution should be analyzed and architected be prepared to field questions from developers. More importantly, be prepared to answer those questions from developer’s point of view using terminology and analogies they understand. Since software architecture concepts deal with systemic issues of a software solution that extend beyond the routine scope of a software developer, be prepared to also educate developers on why it’s important to evaluate and address crosscutting solutions needs. You’ll have to demonstrate why a software architecture centric view is necessary and why a given approach (e.g. concentrating on architectural drivers early on) best suits a given situation. And of course the tone of your voice, your presentation style, and the pace of your communication with the development team must take into account the individual needs and backgrounds of your team members.

Remember that the software engineers on your team are also your solution architecture stakeholders.


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Tuesday, November 03, 2009

Need experience planning for and executing a long term project? Run a marathon.

This thought came to me on mile 21 of the Marine Corps Marathon that I ran and finished on October 29th, 2009. Planning, training for, and running a marathon is similar to executing a long term successful project. Both activities require superior commitment, strategic planning, progressive results, and a clear goal.

A marathon is different by definition - it's a solo event. However there are some points of interest.

- Goal. For a marathoner a goal is clear - finish the race in a given time period. A successful project must have a clearly defined goal that can be achieved and measured.
- Planning. Superficially it may seem that planning for training is easy. However poor planning will prevent you from training properly. And you won't be able to catch-up later (an equivalent of Fred Brook's motto of adding more people to a project that's already late will only delay a project). Long runs must be planned - including a day before and runs during the week. Planning for a long term project has the same demands. One must think through the milestones and deliverable artifacts along the way, as well as software development process that's appropriately tailored for your approach.
-Executing. Training (running) is what builds endurance, muscle, and mental capability to actually finish 26.2 miles. Concrete progress, evolving architecture from cartoons to formal documents, core code base that iteratively grows and aligns to design (plan), is the foundation of the final product.
- The race. The actual race is your test of how well you planned, trained, and executed over many months of preparation. The process of deployment to production and a cut-over (or roll out) of a system to users is your mile 10 of a 26.2 mile distance. The other 16.2 miles and how well you enable the system to handle it will be demonstrated over short time while the system is in production and used by actual users.

Why is this important?

Few people have the opportunity to be in the leadership circles of long term (2+ years) software intensive projects, but it's precisely that experience that enables us to understand the fine nuances that dramatically affect design of systems architecture. Identifying and addressing soft architectural drivers in your architecture designs is essential since it's often the organization and not the technology that places the greatest constraints on an architect.

I can't guarantee that training for and running a marathon will make you better strategist or a better architect, but I guarantee you'll have plenty of time to think about this topic when you train and when you run the race.


Constantin K.
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...