It sounds like a simple question: “What is an Architectural Requirement?” Surely it’s simply a need to change the architecture in some way. And surely there’s a clear reason for making the changes.
But it’s not that simple. Sometimes an architectural requirement is confused with an IT requirement. Sometimes it’s seen as the same thing as a business necessity.
Let me illustrate with an example. A client told me recently they had been asked to recommend a new internet platform. They wanted to know if this was an architectural requirement. More importantly, they wanted to know how to make the architectural requirement more effective.
Key Characteristics of a TOGAF Architecture Requirement
TOGAF has a whole phase of the Architecture Development Method (ADM) and a corresponding chapter (17) in the documentation devoted to ‘Architecture Requirements Management’. But this doesn’t really tell you what an architecture requirement is – it merely gives a basic process for managing their documentation.
Other sections in TOGAF describe various deliverables and artifacts that document an architecture requirement. These include the Architecture Vision, Architecture Definition Document, Architecture Requirements Specification, and things like a Business Scenario, Principles, or Architecture and Solution Building Blocks.
A glib answer to our question would be to say that an architectural requirement can be described as the sum total of these deliverables and artifacts! This is certainly how TOGAF would have us document an architectural requirement, but it doesn’t really explain the difference between an architectural and a non-architectural requirement.
Let’s make it easier by listing the key characteristics of an architecture requirement:
- It should describe a necessary change to components in an architecture. This might mean adding new components, removing outdated ones, replacing or improving components, or changing the way in which they are organized and how they work together. In short, what is going to change?
- It should include the reasoning or motivations behind the change. Why does it need to change?
- It should explain why the existing components are inadequate, limiting, or constraining. What problems, issues, or concerns are caused by the current architecture?
- It should outline the available options for future architectures that address all concerns. How will alternate target architectures eliminate the problems of the current architecture?
- It should explain the benefits, value, risks, costs, opportunities, constraints, and future options associated with each alternative. How do we decide between one alternative and another?
- It should outline any alternative routes to close the gaps and get from the current to the target architecture. How do we make the transition or transformation from what we’ve got now to what we’ll need in the future?
To go back to our example, the client asked for help in recommending a new internet platform. Their architecture requirement could be summarized as:
- We want to update the architecture on which the internet platform is based. This requires replacement of the technology platform, which will allow improvements to application functionality and more real-time data processing. This will enable better integration of customer services and generate more profitable online sales. This provides a simple explanation of the outcomes in a way that stakeholders can understand, but which also relates to components in the architecture.
- We need to make these changes because our architectures are outdated and inefficient in comparison with those of our competitors, resulting in a massive loss of market share and dissatisfied customers. The rationale here is clear to all stakeholders – the future of the company is at stake!
- The current technology architecture was developed in an ad hoc manner, so components do not provide a good or strong foundation for the online experience our customers expect. Furthermore, many of the components are no longer adequately supported by vendors, and there is a lot of unnecessary duplication, which makes maintenance costly and frequently disrupts availability. The problem is explained in terms of the constraints imposed by architecture.
- There are two options available to us. Firstly we can outsource the underlying technical platforms, using standard technologies provided on the cloud as a service. Alternatively, we can build an in-house capability using vendor-provided technologies. The alternatives are outlined by describing the end-result, but it is also easy to demonstrate the architectural differences between the two options.
- Using outsourced services and well-defined standards would allow us to incorporate services from multiple vendors – giving greater business flexibility and functionality. However, this approach would require greater coordination at the business process level, which might be more complicated than management would tolerate. An in-house capability might be a simpler solution, but this would probably restrict us to a single vendor, which in turn might limit business process and product flexibility. The factors that will influence the choice between the alternatives are clearly summarized.
- Initially, we would need to replace the underlying technology platform with either an outsourced service-based environment or an in-house vendor solution. This would simplify our technology architecture, reducing costs, improving availability, and reducing maintenance overheads. This would be followed by improving the intelligence and usefulness of information via improved integration in the data architecture, allowing better marketing and generating higher sales. Finally, we would be able to make parallel improvements to application functionality and business processes, making it easier for customers to buy products and services and making interaction with our sales teams simpler. This clearly shows the key steps and the value they can deliver.
Obviously, this example is greatly simplified. There would need to be more details, the arguments would need to be firmly based on complete descriptions of the current and target architectures, and the possible road-maps to make the changes would need to be clearly laid out. But hopefully, this simplified overview has emphasized the key aspects that make up a typical architectural requirement.
One Final Point
Remember that this is an ‘architectural’ requirement. If you don’t relate everything to the relevant aspects of your enterprise architecture, then it is simply a ‘requirement’!
