Back to Basics

Mark Perry - Jan’06

Having had a busy 2005 the Christmas/New Year break was a good time for some reflection on the
various architecture initiatives and programmes I have been involved in over the last year. One
repeating conclusion was how easy it is to become caught up in the detail of an interesting technical
discussion or a particularly juicy design topic and forget the underlying basics which help make
architecture a reality, and the teams responsible for it effective. Even though many architecture teams,
particularly the larger more established ones, will have people focused on the quality management
aspects of design and governance, I thought it worthwhile to share my thoughts on the basics which
all good architecture teams and their members should never loose sight off.

The Process
How many times of you been involved in work around
processes only to see it become a complicated web of
relationship structures, process models and dependency
definitions which quickly become incomprehensible to anyone
but those involved in the original process analysis and
definition. This need not happen if we keep the perspective at
the right level. Think about the basic steps which we all
recognise in the formulation of any solution – be it an
architectural framework or a system design. There are
requirements which need capturing and clarifying, there are
options which need identifying and assessing, and there are
design decisions to be taken and communicated. Even if we were able to remember just these three
absolutely core steps, and make them evident in our roles and in the production of the supporting
documentation things would become just that much clearer for all those involved. This clarity is even
more important in an Enterprise Architecture sense because of the environment coverage and
audience diversity which has to be addressed when communicating architectural process and
outcomes.

We will always need the appropriately skilled people, and supporting tools, to take the analysis and
definition of process into the working detail and to ensure people are managed against it, but we
should all look to remember and promote these core process steps. Being able to differentiate those
activities associated with (1) the capture and understanding of requirements and (2) those associated
with the assessment of options and the design of solutions cannot be emphasised enough – yet I still
see people getting the two areas confused with the corresponding ‘fall out’.

The Product
There is always a lot of debate about the output from an architecture group and, to be quite honest, a
lot of it really looses the essence of what we are trying to communicate as architects. Again, going
back to basics it really should not be too difficult to capture key statements about the clients strategy
goals, their current business and operating environment, the organisation structure and geographic
locations, their current IS/IT deployment and standards, and finally the specific topics/problems which
need solving. In other words think about those things which provide the context.

A clear documentation structure and simple but enforced version

control can go a long way in ensuring the teams involved stay
focused on the core client objectives and constraints.
Sophisticated requirements management processes and tooling
can provide real additional benefits but even these won’t get you
very far if the basics aren’t in place.

Design models are always good for a heated debate. Should you
use this architectural framework and methodology or that model
standard and supporting tool. Once again – ask yourself what are
we trying to communicate and to who as we go through the design
process. First - think of the solution concept – what users need to
access the solution, where are they roughly, what information do
they need, how do they/could they operate (e.g. office, mobile, etc), what availability do they require.
At this level readily available diagramming tools can be very effective communication tools.
Secondly – think of the logical topology and functions – should the system be
central/federated/distributed, what major components are required in terms of business logic/data
stores/networking/input/output/working processes/etc, what throughput and capacity do these
components require. Even at this more elaborated design detail fairly standard diagramming
packages can capture all you need to then frame your thinking about the physical mapping onto
specific technologies and products.

There will always be cases where the user operating environment and client solutions to be
progressed need sophisticated analysis and design methodologies and tooling (even more when you
consider the ongoing task of system change management and the associated impact/risk assessment
needed) but often there are real advantages to spending some time thinking about what it is you
actually want to have as documented architecture output to share with both clients and your internal
teams. Also think about the key architectural principles and decisions and how you might want to
document and communicate them, e.g.:

• Off-the-shelf v. bespoke v. composite.

• Structured and inspectable assessment and selection of products.
• Strategies for reducing technology diversity.
• Intercepting and influencing of delivery programmes.
• Reuse (of work products and solutions/parts).
• Mature v. innovative technologies.
• Business solution and technology roadmaps and long-term plans.

Being clear on how these topics are captured and shared is key to informed debate, decision making
and solution/technology planning – things which all enterprise architects should be passionate about.

The People
We probably all know that at the end of day, how well a job is
done is down to how good the people are. Now, I don’t expect to
have a supply of really good experienced architects always on
hand to choose from. But having clearly defined roles and
responsibilities helps everyone develop and do their job that
much better.

This is particularly true in terms of the major areas of

‘requirements analysis’ and ‘solution design’. Consider now on
the teams you are part off or involved with – is it clear who is the
requirements authority (i.e. someone you can rely on in terms of
knowing the client’s business and who can speak authoritatively
on their behalf on what they really need). Likewise, is there an
individual or group recognised as the design authority (i.e. someone you can rely on who knows the
strategic IS/IT direction, the applicable standards and can understand and influence the overall
solution such that it meets requirements). I have certainly encountered teams where, in a number of
cases, I think the answer is either ‘No’ or ‘Unclear’ and I am not sure which is worse! So think about:

• The team structure and expertise to cover all necessary EA domains.

• Having clear roles and responsibilities written down - overlaps can be worse than gaps.
• Define working principles and deliverables.
• Balancing project/delivery exposure and general architecture awareness.

For me getting roles defined and accepted by all is key. And bear in mind that for these roles to
maintain their position of authority there is the need to continually balance project exposure and
general architectural/solution awareness to ensure a wide experience and understanding of business
issues, available design options and solution delivery – that’s how people build their credibility and
ensure their authority can be effective in influencing outcomes in the right way.

The bottom line: So an effective architecture team exhibits strong leadership, defined team structure
and roles, effective and consistent documentation, informed decision making, clear design models
and focused communication. The key is balancing structured and defined working practices with
enough documentation to provide the ‘statements of record’ – we all at some point need to go ‘back
to basics’ and say why things were done the way they were!