Technical and Business Architecture

If architecting was only about solving a technical problem, then this discipline would be strictly under the computer science domain. What makes software architecture a child of the software engineering domain is the fact that an effective solution needs to solve business problem or achieve a mission.

It’s clear that an architect has to work works very closely with all stakeholders in order to understand the root of the problem for which a solution has been envisioned. There are two core qualities that an architect must exhibit. First, an architect must have an implementable vision of the whole concept from start to finish (if you don’t who will?). Second, an architect must intelligently question the business problem that a customer is trying to solve. This is very important, because this will minimize the risk of the solution not fitting into the existing (or future) technical and business infrastructure.

In mature organizations both software architects and business analysts speak a common language and work jointly to make sure a solution supports a business problem. In other organizations the burden often falls on the software architect to make sure that a solution design exhibits conceptual integrity from the business point of view. It’s not uncommon to have a group of business stakeholders individually represent what they want to see come out of the solution. But someone (business architect role) has to take ownership of the discrete needs and integrate them together into a comprehensive plan. Not every software architect is capable of deriving the root cause of a problem, and that’s OK. But a mature software architect would know when to bring in help to enable him to design the right solution.

Due to constraints thorough analysis is not always possible. This is where an architect must make a judgment call and make progress based on the known factors. In such situations it’s imperative to document risks and limitations of the solution so that the final result is judged against this segment of time.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Business Improvement Through Better Software Architecture

In the 10^th edition of The Architecture Journal, published by Microsoft, a son & father pair have done an outstanding job describing architect roles in business software development. It’s not very often that you come across such a well written, eloquent, yet terse piece of writing that energetically captures the responsibilities of architect roles and the relationships between those roles.

The authors, Sten & Per Sundblad, state in the opening paragraph that “business software exists for one reason only: to support the business and its activities … there is no other reason for business software.” This is the premise of their philosophy and a fact that software architects often forget. Countless articles have been written over the past five years on lack of alignment between IT and business. Few of those articles presented the issues and solutions with proper level of abstraction that made reading this article equivalent to reading a really book that you don’t want to end.

The article is authors’ perspective and by no means a standard, but it’s a good use of your time and deserves placement in the Essential Selection.

Firebrand Architect on duty: CK