What is Architecture?
Why should you care? If you'e a software architect, you might want to have some idea of what it is you're supposed to be delivering. If you're a manager, you might want to have some idea of what an architecture can do for your project. If you're a developer you might want to know what an architecture can do for your design and development. If you're none of these things then you must really have something better to do than read this blog right?
So despite my earlier post about the woes of an industry that relies on using analogies with other endeavours, I thought I would take a stab at defining what Architecture is - at least so far as it relates to Software Development. Why would I want to do this? Well, mainly because I've heard the cry 'what we need here is an architecture' or 'what we need here is an architect' pretty often but no one seems to be able to really say what Architecture is. What problems should it address? What are the deliverables? There seems to be no clear definition. Many definitions are self referential a bit like these two entries from dictionary.com:
hill [hil] –noun
1. a natural elevation of the earth's surface, smaller than a mountain.
1. a natural elevation of the earth's surface rising more or less abruptly to a summit, and attaining an altitude greater than that of a hill
tnWell. That's cleared that up then. Fortunately for us we all have a fairly clear concept in our head of what a hill is and what a mountain is. Unfortunately for us that concept varies greatly depending on where you live - A mountain in Scotland barely classes as a bump in the road in the Himalayas. The situation with software architecture is no better, and I would go so far as to say it is much worse. Fortunately for you, lucky reader, by the time you've finished reading this post you'll be in no doubt about what software architecture is (hooray for me) that is if you haven't died of boredom first,
I'll start with a quote:
From Garlan and Shaw, 1993, p. 1:
…beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem.
Structural issues include:
- Gross organization and global control structure.
- Protocols for communication, synchronization, and data access.
- Assignment of functionality to design elements.
- Physical distribution.
- Composition of design elements.
- Scaling and performance.
- Selection among design alternatives.
It pretty clear from this that what we have here is a big hill. Architecture is really 'design'; its all just a question of scale. I think the list above fairly clearly shows what design items should fall into the purview of architecture, but utlimately the borderline between architecture isn't really well-defined - its fuzzy - or to continue with the hill analogy, its a slippery slope.
I think, however, that its worth delving into some of those items a little more deeply. These are the ones that seem to cause the most trouble in the projects I have worked.
Scaling and Performance
I'll use another quote, this time from 'Documenting Software Architectures, Paul Clements et al., 2003'
For nearly all systems, quality attributes or engineering goals - such as performance, reliability, security or modifiability - are every bit as important as making sure that the software computes the correct answer. Architecture is where these engineering goals are met.
Every software engineer has these issues in the back of their mind when they're writing software, but its one of the puropses of an architecture to make sure that the requirements for these metrics are clearly stated and that the overall system design will meet them. A talented and experienced engineer will be able to make sure that the components they are working on will meet these requirements but an architecture must be able to provide guidance and expertise to fill in where the skill or experience are lacking and, more importantly, must be able to make sure that the whole system meets the requirements and not just the individual components.
Selection Among Design Alternatives
There are always many ways to do things. Even where the mechanism is fairly clear, i.e. "we will use a relational database to store persistent data", there are often decisions to be made about exactly how something gets implemented, i.e. "do we use Oracle, MySQL" etc.. Sometimes there isn't much to choose between alternatives. Sometimes the choice can have an impact on seemingly un-connected parts of the system. Sometimes a choice will require re-evaluation of other choices. An architecure provides a holistic view of the system and thus is uniquely positioned to be aware of all of the pro's and con's of the various alternatives including the knock-on effects of a choice and state which of them is going to be used and why.
The reason for a decision is often not a technical one, often it is about mitigating risk. I will quote myself this time:
In all software development there is risk. Risk that the technology will become obsolete, that vendors will cease trading, that third-party software will malfunction, that requirements will change, that the product will contain bugs. Architecture should seek to mitigate these risks.
A Four-Point List
If you want a simple list that you can quote to people without their eyes glazing over, I think this is a reasonable attempt:
Architecture addresses:
- Gross structure and behavior
- Fitness-for-purpose
- Risk mitigation
- Technology arbitration
What is an Architect?
Great. So what is an architect supposed to do? What is their job description? Well, I belive an architect:
- Abstracts the complexity of a system into a manageable model.
- Gets the architecture defined, documented and communicated.
- Makes sure that it comes out in stages in a timely way so that the overall organization can make progress before it's complete.
- Progressively makes critical decisions that define a specific direction for a system.
- Makes sure that the architecture is not only the right one for operations, but also for deployment and sustainment.
- Understands and plans for evolutionary paths. Plan for new technology insertion.
- Fights entropy that threatens the architecture.
- Manages risk identification and risk mitigation strategies associated with the architecture.
- Sets quantifiable objectives that encapsulate quality attributes of a system.
- Makes sure everyone is using the architecture, and using it correctly.
- Participates in design reviews but not code reviews.
- Resolves disputes and make tradeoffs.
- Resolves technical problems.
- Identifies and closes architectural gaps in requirements.
- Acts as an emissary of the architecture.
- Inspires, mentors, and encourages colleagues to apply intelligently customized industry best practices.
- Creates and distributes tailored views of architectures to appropriate stakeholders at appropriate intervals.
- Acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development.
If you can do just a few of these things I think you're probably doing a good job, but as your colleagues (and you) question what it is you bring to the table, this is a good list to come back to.
What an Architect Isn't
And just so we're clear, this is what an architect isn't:
- A business analyst
- A technical lead
- A developer
- A sales engineer
- A product expert
- A project manager
This is not to say that an architect should never take part in these activities, just that their primary focus is architecture. In particular it is extremely important that an architect has credibitlity with each of these groups and with management. It is difficult, if not impossible to maintain that credibility without taking part in these activities to some degree.
