Sunday, March 22, 2009

Complexity in Software Architecture and a new architect role

Things are just getting worse for software architects. Relative stability of business models and computing paradigms of the 2000's has vanished. Making the right early design decisions has become very difficult. Keeping up with technical and operating environment complexity has become nearly impossible.

Humans deal with complexity through abstraction. With rapid growth of complexity in the software architecture domain (both business and technical perspectives) we're now seeing divergence of software architect roles. It's not possible to be a great security architect, a great performance architect, and a great general software architect at the same time. Recently architects have been specializing, often not by choice, to fit the business domains and their operating environments.

The important point is that a new breed of architect role needs to be officially recognized. It may be called a composer, orchestrator, manager, or a solution architect. In this role an architect would only be responsible for creating and maintaining the conceptual integrity of a solution. The conceptual integrity then needs to be maintained and managed in light of changing environment (new constraints, funding, requirements, policy, staff). This architect role would be responsible for making the right timely decisions as to when to bring in appropriate experts. Some may argue that this role exists now and it's the role of a software architect, but it's not possible for a single person to orchestrate the activities of other specialists and be responsible for technical structure of the whole solution.

Over the past few years ( 2006 - 2009) a new trend has developed where more and more architects specialize in a specific area of quality attributes (e.g. security, performance, usability) and relive themselves of duty of the end-to-end solution ownership. There is no question that specialization is necessary to gain the appropriate level of technical depth to be effective, but who is left to be responsible for the conceptual integrity of a solution? Often this role is filled by someone who doesn't understand how specialists work together and how they must be integrated together. Yet this is a very important role, because in order for specialists to be effective their input must be appropriately timed. For example, when was the last time security was effectively retrofitted into an already existing solution? An orchestrating architect needs to recognize the need for a security specialist and then figure out when to incorporate that expertise into the project.

This orchestrator role doesn't explicitly exists because organizations expect professionals to be either technical software architects (sometimes listed as senior software engineers in job advertisements) or project managers. The recognition for something in between doesn't exist.

Successful projects have someone who maintains the end-to-end perspective. It's a challenging role as a person doing this is likely doing this along a set of other major responsibilities.

As the complexity of our computational environments and the complexity of business solutions has expanded we need realize that in order for software architecture specialists to be effective their work needs to be thoughtfully orchestrated by someone who has time, resources, and authority to create and maintain the end-to-end conceptual integrity of a software solution.

Constantin K.
Firebrand Architect®

No comments:

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...