This is a question that I am regularly asked and is often the subject of great debate within the information technology community.
My colleague, Simon Watts, recently wrote an article titled “What is I.T. Architecture?” in which he concluded that architecture is simply the collection of principles and operational
requirements that are being applied to a business in order to solve and govern its strategic data processing requirements.
Although architecture is a diagram-oriented activity, the diagrams are generally used to present the summary of a set of factual statements and to break a complex problem down into manageable
components.
This leads to the conclusion that IT architecture is an “objective” based activity whose primary purpose is to define what is required to provide a solution to the business requirements
defined in the analysis phase.
Certainly, this conclusion is supported by the major architectural frameworks, such as Zachman and TOGAF, but is, of course, not the full story!
If architecture is an objective-based activity, then where do activities such as choosing technology platforms, design patterns, defining database platforms and so on fit in?
The choices can have significant implications on company costs, both balance sheet capital expenditure and profit & loss accounts, and future business capability in addition to the more obvious
programme-related concerns such as ease of implementation, availability of experienced staff, robustness and stability of chosen platforms.
They are all decisions that are obviously more important than mere implementation detail so need to be dealt with at the architectural level but aren’t really architecture per
se because they don’t meet the objective characteristics of architecture.
This, in fact, is what we tend to mean when we talk about design rather than architecture and leads us to the title of this discussion, namely:
“Architecture Is Objective, Design Is Subjective”
Architecture and design are nearly always bundled together into a single activity carried out by “The [Insert Specific Role of Choice] Architect” and the individual features of the
final architecture are rarely separated into the “objective” or “subjective” aspects.
However, there are many reasons why they should be kept separate, including:
- Architecture is always (or should be) aligned to the overall business strategy whilst design is usually aligned with the available resources.
- Business stakeholders usually don’t care about technical details of the design – the attention of many an audience has been lost by boring them with more detail than they are
interested in. - The merits of each architectural component can be quantified and measured whilst design aspects are debateable. Removing design from architecture increases the chances of reaching general
agreement over the approach without subjective arguments over technical merits. It improves “time to market”. - The objective aspects are a matter of necessity to operate the business whilst subjective features can be modified, superseded or replaced over time without impacting the nature of the
business.
For many people who perform both roles in an environment where the separation isn’t important, this is probably an academic discussion; but, in some cases, it may actually be that
architecture and design must be kept separate for business reasons.
Consider the following high-level architectural view of a particular business sector (covering the UK Energy Performance Certificates marketplace):
Figure 3: Mouse over to enlarge
It isn’t the full story of course – there’s a lot of requirements definitions, interface specifications and operational constraints defined behind the scene – but I think is
a relatively simple high-level architectural diagram to illustrate a point. It contains all the significant detail required to understand what components will exist in the system, but says nothing
about how they will be implemented or the tools and technology that will be used.
In this particular case, the separation of architecture from design is very, very important because:
- The accreditation bodies were all separate companies with their own ways of conducting business and their own in house technical platforms. Some were Java shops and some were .NET and some were
plain old C/C++. - The two central data repositories were externally procured and managed by a third-party supplier. The platform was at their discretion, and all they were provided with as part of the
procurement was the architectural framework and a set of objectives to be achieved.
All of these organisations needed clear guidance on which aspects were fixed and which aspects open to interpretation by them. They needed to know the objective but not the subjective aspects of
the environment.
Unfortunately, separating the architecture and design is much easier said then done because it is not always clear whether someone is being objective or subjective when making an assertion about
the problem they are trying to both define and solve.
Over subsequent articles, we’ll explore some of the issues in separating architecture from design, such as:
- How do we recognise when something is objective or subjective? There are many terms, concepts and patterns that in some contexts could be regarded as architectural concepts and others that are
simply approaches to design. - How do we enforce the separation between architecture and design when the activities are carried out by the same role?
- How do we handle evolution where a design approach evolves into an architectural constraint?
For example, until recently using XML would have been regarded as a design issue because there were many alternative methods to specifying interfaces between components. Nowadays, XML is pretty
much the de facto standard and is at the point that “it goes without saying” that all public interfaces should be in XML unless there is an exceedingly good business driver to use
anything else. It has stopped being a design decision and become an architectural decision. - Removing “mere implementation detail” – how do we strip an architectural proposal down to the absolute minimum so that irrelevant information doesn’t cloud the overall
picture? - What are the minimum artefacts required to produce a coherent enterprise data architecture? For example, where does the business information model fit into the enterprise data architecture
picture? Is it an architectural artefact or just a design artefact?
