Scaling Things Down - Enterprise Architecture

Enterprise Architecture is often sold as 'a way of understanding your entire business - from the value you're providing to your customers to each piece of hardware that's used in delivering that value.' While the traceability of customer value through software and finally to the hardware that supports the delivery of that value can be very powerful, it's very daunting starting an enterprise architectural project - the benefits of the work might not be seen for several years.

This blog post describes how I used TOGAF - a framework for creating enterprise architecture - on a tightly constrained part of the enterprise. This delivered business value in weeks instead of years.

TOGAF? What's that?
TOGAF is, well, complex and comprehensive. In it's simplified essence, it consists of a framework to describe enterprise architecture, a method of developing the architecture, and a repository to reuse pieces of existing architecture. Of the most interest, and key to understanding TOGAF, is the framework to describe the architecture. It consists of four deeply linked architectural types:

1. The Business Architecture (who does what in the organisation).
2. The Application Architecture (the set of logical and physical applications that support the people who do stuff)
3. The Data Architecture (the logical and physical data that is used by the applications)
4. The Infrastructure Architecture (the hardware that stores the data, runs the application, and transfers data from one place to another).

Over the top of these four pillars of architecture is the 'enterprise architecture'. This is, typically, a set of business scenarios and capabilities.

That seems like a lot of work!
Scared yet? It is complex. Business Analysts are always at risk of getting themselves into analysis paralysis and this is the perfect tool to do exactly that. Luckily, TOGAF provides two methods of avoiding analysis paralysis: scope control; and detail control. Scope control is about managing which parts of the organization you are examining. Detail control is about managing the level of detail you need to describe in order to deliver value.

This is an important point so I'll repeat: we must not forget that the purpose of doing architectural work is to deliver value to the organization.

Case Study
As it happened, I had a lovely piece of work fall onto my lap. The Business has a semi-automatd process that takes weeks to perform - and it has to happen every month during peak staff workloads. They want full automation of the process. This will reduce demands on key staff at peak times, deliver greater value to customers (as the customer will get timely reports), and increase team moral (as the team doesn't particularly like doing it). As they've been burnt by development costs before (who hasn't!), they wanted a gap analysis of what will need to be done to move to full automation.

Luckily, TOGAF is especially good a gap analyzes. The development method is quite clear about creating a vision, defining the current architectural state, defining a future architectural state, and determine a path to move from the current state to the future state. However, telling stakeholders that you're doing architectural work to understand an existing process doesn't go down well - so I didn't tell them.

To start the analysis I first decided on the scope of the analysis. The breadth of the analysis was tightly constrained to the process - production of a particular report for our customers. The depth was less well constrained. I had to leave it as "enough depth that we can determine the gaps, and the cost/benefit of closing each one". With that scope in mind, I dived in, interviewed, works-hopped, and did the normal BA type things. The resulting report was comprehensive, detailed, and had all the information anyone would ever want. To make it readable I added a chapter for high-level results and recommendations. I don't think anyone from Business read beyond that.


TOGAF is a thinking tool
Clearly TOGAF can scale down successfully to be useful on smaller pieces of work. The ore interesting thing was how using it on a smaller piece of work clarified my thinking. The separation of the way the business works from how the technology works clarified my understanding of both, let me tap into expert knowledge at the right time, and helped me ask the right questions. It also gave a nice report structure to describe a very messy process (the business work-arounds due to technology were nasty!).

On a final note, I found TOGAF a very good thinking tool for the larger problems that can't be modeled in a business process model or in a use case model. If you think you've mastered both those thinking/analysis techniques, then give TOGAF a look now.