How mature is the software architecture discipline?

In 1996 Professors David Garlan and Mary Shaw of the Carnegie Mellon University published an influential book: “Software Architecture – Perspectives on an Emerging Discipline”. In chapter 1 the authors discuss a model for the evolution of an engineering discipline. The diagram can be found here.

Before discussing the diagram let’s establish a few key concepts. With respect to maturity of engineering disciplines based on pure sciences (e.g. chemical engineering) the software engineering discipline and to a greater extent software architecture discipline is generally considered to be very immature. But why? The authors state that “engineering practice enables ordinary practitioners create sophisticated systems that work … reliably.” Has the software architecture reached this state?

It’s important to note that engineering discipline practitioners make the bulk of money by solving routine design problems. Routine design aims at “solving familiar problems” and designing solutions by using the knowledge base from previous projects and experiences (e.g. an e-commerce shopping cart site). Innovative design aims at solving original and unique problems, such as controlling an unmanned helicopter through a remote control center. It’s important to note that with software architecture discipline the bulk of the money is made solving routine problems by ordinary practitioners.

So how do engineering disciplines evolve?

The engineering disciplines evolve from ad hoc state in two steps. Initially, talented and passionate amateurs pioneer the discipline. They achieve their goals by all means necessary – usually irrationally using available resources. Later the routine production occurs. With time the need for advancement arises and supporting science for an engineering discipline emerges. The maturing science eventually turns into a “professional engineering practice,” where science will become the main driving force of a discipline.

What will it take for the software architecture discipline to become mature? This question will be addressed in the future post.

Other ideas to think about: if software architecture discipline is not based on hard science at its higher levels of abstraction, will it ever reach the same level of maturity as a civil engineering?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Software Architecture is about people

At its core the software architecture discipline is about people and our obstacles are a figment of our imagination.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Boundaries between "Architecture", "Design", and "Implementation" formally defined

Insightful paper by Rick Kazman & Amnon Eden, presented at ICSE 2003, that defines the boundaries between "Architecture", "Design", and "Implementation" by formalizing the ‘Intension and the Locality criteria, which imply that the distinction between architecture, design, and implementation is qualitative and not merely quantitative.’

Basic understanding of formal notation (esp. Zed) is necessary for enriched reading experience.

Download the paper from SoftwareArchitectures.com or SEI.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Microsoft's Architecture MVP Changes

In late February of 2008 Microsoft dissolved the Microsoft Architecture MVP award as part of realignment of the MVP program to be more product oriented. Dissolved is a wrong word … so read on. This came as a surprise to many award recipients - including myself – who lost a “nice to have” title. This development, however, had a very positive impact on the Architecture MVP community, because it forced the architects ask themselves some hard questions about their role in the community and the role Microsoft plays in the software architecture discipline.

This post features some highlights from the ferociously bubbling listserv.

At first there was confusion. Participants understood the reasoning behind moving towards a product oriented approach, but they couldn’t fathom the disappearance of the architecture competency. Then there was anger – well summarized by one of the participants: “I believe the shutdown of the MVP Architect program is just one more piece of evidence that … Microsoft does not appreciate the role of the architect in driving large buy decisions.”

Then a word of wisdom came from Simon Guest. In order for the MVP program to grow the structure has to change. MVPs will be aligned to a product, but will be able to select a discipline such as architecture. Simon then called for an open forum at the MVP summit in Redmond on April 15^th.

Identity crisis started to emerge – some participants, including Martin Fowler, voiced their reserved opinions about the value of the MVP award. Valid questions arose – why do architects communicate so little with each other? What role do architects play in organizations? What do they do for Microsoft? The consensus was clear – although there is a clear need for robust architecture communities the MVP award infrastructure didn’t make individual architects feel part of a single unit.

Finally discussion merged onto taking proactive steps to define the scope and purpose of the group. Familiar questions arose: how do we define different types of architects? What are the definitions of architecture and architect? Should we just take some definitions from IASA? Microsoft has established a work space where the discussion of these various topics will commence.

There are no clear answers, but there are good questions – Microsoft is moving in the right direction albeit at its own pace.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Engineering elegance

I came across this quote on definition of engineering elegance by a French aviator and author Antoine de Saint- Exupéry: “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Is this statement applicable to software architecture? Aren’t architects constantly trying to add features that fulfill more and more functional and non-functional requirements? Aren’t multiple layers of security always good? Wouldn’t installing a .NET framework 3.5, for example, is better than .NET 3.0, because it has more features?

Perhaps those who see the power in this quote are the architects who are able to truly understand the essence of a business problem; it is those who can skillfully control the scope. But is this applicable to the software architecture domain as it stands now?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Selecting COTS software under pressure (Forrester and Gartner)

This happens on many projects: everyone agrees that the core of a solution (e.g. workflow engine) will be purchased instead of built from scratch. This is an absolutely rational decision for most enterprise applications. The next question is which vendor to select.

The rational approach is to identify the core functional requirements and key quality attributes that the solution must exhibit. This is an absolute must; because without understanding what you need you will not be able to objectively judge your options. The criteria on which you should evaluate you COTS software candidates must be granular and quantifiable to the degree that makes sense. Each criteria element needs to be weighed against all other chosen consideration elements so that all weights add to a whole. E.g. In case of workflow COTS software the number of concurrent workflow processes that the solution must support has to be at least 400 and this criterion has a 15% importance in relation to other selection elements.

The next step is to conduct evaluation of the market space for available vendor solutions. A number of solutions will not meet the top selected criteria based on the marketing information from the vendor, but few will emerge as potential candidates. Since COTS software will be an integral part of the solution a targeted proof of concept should be implemented and results judged against the established criteria. The outcome of the test along with other evaluation criteria is used to make an objective and rational decision.

If a decision on the COTS software absolutely has to be made in a period of time that doesn’t allow a proof of concept, then you should buy the intelligence from a third party that has done COTS software evaluation for you. Both Gartner (Magic Quadrant) and Forrester (The Forrester Wave) provide analysis of various COTS products that fulfill a particular segment of business applications (e.g. BPM tools). Each vendor solution is evaluated against a wide range of criteria. These reports provide very valuable insight, but without objectively understanding the needs of the solution you’re architecting it’s not possible to fully utilize the insight provided by a third party.

In general a Gartner, Forrester, or another 3^rd party report should be used in any COTS software evaluation whether you’re pressed for time or not.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Advice for apprentice software architects

The software architecture discipline has matured to the point where the core tool bag for architecture analysis and design can be learned by any serious software engineer. But this doesn’t mean that architect’s experience is no longer an important attribute of architect’s character.

The best way to learn is by doing. To quote Lakota Indian saying: "Tell me, and I'll listen. Show me, and I'll understand. Involve me, and I'll learn." Apprentice architects must seek out opportunities to work on architecturally significant aspects of various projects. Diversity here means working on projects with different SDLCs, projects of different scope and size, and projects across different functional domains. Diverse experience – preferably across different organizations – will enable an apprentice architect make better decisions in the future as the repertoire of skills and knowledge grows.

Everybody wants an architect with 10 years of experience, but nobody wants an architect with 1 year of experience ten times.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Neglected Aspects of Software Architecture

Todd Kaiser, a Chief Architect of Government Systems at Raytheon Intelligence & Information Systems, delivered an outstanding presentation at the 2007 SATURN workshop. The absolute beauty of the presentation is simplicity with which he delivered a very important message: some software architects ignore non-technical aspects of software architecture that results in “collateral damage.” In addition to concentrating on technical pillars of a solution: data, structure, and behavior, an architect must also actively weigh managerial, financial, and contractual aspects of software architecture. Your personal architecture world may be different, but Todd Kaiser’s presentation succinctly delivers the message that applies to most architects: architecture is more than just technology.

SATURN 2007 presentation on Neglected Aspects of Software Architecture.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Responsible Software Architecture

SoftwareArchitectures.com is propelling the concept of responsible software architecture. This concept is based on philosophy that every decision made by a software architect must be conscious and must be supported by a judicious decision making process that clearly demonstrates why the chosen design alternative was selected out of a range of other possibilities.

Every decision made by a software architect is made in some context at some snapshot of time. The context is defined through architect’s understanding of personal capabilities, requirements, constraints, financial resources, time, capability of the team, etc. The context changes over time, so it’s imperative to document the background against which a decision was made. When someone questions a design decision or suggests a better solution an architect must provide a scientific justification of his or her decision – without it architect’s credibility and the credibility of the solution may be compromised.

The concept of responsible software architecture is very powerful, but few architects live by it. Think about two or three most recent software architecture design documents that you reviewed. How many documents clearly explain the way key architectural decisions meet business drivers and why selected architectural approach is better than listed alternatives? Not every decision needs to be documented with an elaborative set of alternatives, but all key decisions need to be explained. Key decisions are architecturally significant choices that if changed have a profound impact on multiple quality attributes of a system.

A responsible software architect must sincerely believe that a business problem, and not technology, drives the solution. Technology may be the core vehicle for delivering the solution, but it’s not the driver – this is a paramount concept. Because technology is not the driver a responsible architect must be able to initially reason about a solution without technology specific terminology. The point here is that selection of a technology (platform, development tools, COTS software, etc.) is an architecturally significant decision that constraints the solution. An architect must be able to provide a judicious explanation as to why selected technology was chosen. Once that decision was made it’s only natural to think within the context of selected technology.

Some software architects have too much vested interest in a given technology so they only design solutions with that framework in mind. This clearly limits the range of solution alternatives, but it’s not as limiting as reusing the same architectural approach from project to project without justifying the reason for doing so. For example an architect who designed web based applications using MVC architectural style for the past four years may be inclined to use it on the next project even if a Front Controller style or an AJAX based pattern may be more appropriate. Similarly if an architect is used to a working with a process intense SDLC he or she may push for it without realizing that a new project requires agile JAD/RAD approach due to its research and development nature. The latter examples demonstrate the proverb: “When all you have is a hammer, then everything looks like a nail.” For an architect to be responsible he or she must question their decisions and make sure that appropriate audience is able to understand the reasoning behind the decisions.

SoftwareArchitectures.com is currently establishing a Center for Responsible Software Architecture. Join the discussion on responsible software architecture in a specially created forum. Each post will earn you a chance to win Evaluating Software Architectures: Methods and Case Studies book (through October 15 2007). Registration required to view and post.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Revisiting the definition of software architecture

When was the last time you thought about the definition of a software architecture? It has been quite some time since I read the definitions posted on the SEI’s Community Software Architecture Definitions page. Some interesting definitions:

Eoin Woods (Software Architect, Investment Bank, London, UK): Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.

Adu Matthaeus (Systems Architect, Eikon, Centurion South Africa): A configurable skeleton of any kind of software beast on which you hang implementation specific muscle to make it live.

Jeff Winter (Software Engineer): … Architecture is necessarily a series of abstractions, depicting details relevant to one perspective while suppressing details relevant to other perspectives, and therefore expressed as a series of complimentary views. To say what those views are, you must embrace some ones method or make up your own.

Steve Wright (Consultant - Sr. Data Architect, Knowledge Management, Boston, MA): Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed.

Balakrishnan Thiruvadi (Technical Manager, HTC Global Services, Chennai, India): It is an art of defining, implementing, maintaining system and software environments that will assist and grow with business requirements.

Tim Simmons (Student, Southern Adventist University, Nashville TN USA): The architecture of a software system is its very essence. It is not merely a schematic showing interconnected components, but a description of those components and the way in which they interact. It is the foundation upon which the entire system is built.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Software Architecture Discipline Splits

We dreamed about the software architecture discipline becoming a mature discipline similar to the way civil engineering has evolved over time. To a certain degree this has become true: a unique set of skills is not required to develop a basic accounting back-office suite or a large scale eCommerce site. Banal solutions are reproducible by anyone with basic software design knowledge. This is good, because seasoned architects are now reaching out to solve more challenging problems.

Up until now software architects were doing two jobs under the same title: mature software engineer and mature software designer. [Note that the word 'mature' is used over 'senior' since age does not equate to seniority or ability to design complex solutions.] The software architecture discipline will eventually split into those who concentrate on the art of the discipline and those who specialize in the science of the discipline. This is inevitable due to the ever-growing complexity of responsibilities a person with a software architect title.

All software architects need to have experience from the trenches (working on serious projects in the real world) doing programming, design, and experience in all other parts of the SDLC experience. However, the architects concentrating on the 'art' aspects of the discipline will find themselves spending more time understanding and eliciting the business problem and conceptualizing the solution. The architects concentrating on the 'science' aspects of the discipline will provide cross-check the concept and provide insight on concrete implementation options. The soft side of the architecture discipline will deal with the human aspects, while the hard side of the architecture will address technical aspects.

The need for further concentration by means of splitting architecture responsibilities into soft and hard sides comes from increased demand from the business users to develop solution that solve a business problem, as well as the need to deal with the continuously growing complexity of implementations and overflow of new technologies and tools.

Firebrand on duty: Constantin K.