February 23, 2009

Iterative architecture development and tooling

I have recently blogged about the work on enterprise architecture by Tom Graves, an independent consultant from Tetradian. Tom has authores several books, including Real Enterprise Architecture - Beyond IT to the whole enterprise (see the books section of Tetradian). I had briefly scanned this book before, but I'm currently reading it cover to cover and must say that I'm increasingly enthousiastic about it.

The core assumption in the book, as in many books on architecture, is that the enterprise is a system. Architecture, then, is a property of the system: 
Architecture is the integration of everything the organization is or does.
As many books on architecture, this book also uses a framework. This one, however, focuses not only on results (e.g. Zachman) or process (e.g. TOGAF's ADM) but on both. So far the meat of TOGAF has always been the ADM. I'm not exactly sure how good the content-framework of TOGAF 9 is as I haven't studied it in detail yet. More on that soon. Either way, a other strong points about this framework are the iterative nature, allowing several degrees of freedom in developing architecture, considering architecture maturity as part of the framework etcetera. The core of the approach is illustrated by the following figure:


Requirements (with respect to the architecture) play a central role in the framework. Even more, 5 distinct views on the architecture are considered to derive / structure these requirements. These 5 views are dubbed the 5 p's: People, Purpose, Preparation, Process, and Performance. As architecture is assumed to provide a holistic view on the enterprise, each of these views includes, within itself, a sense of all perspectives as illustrated by the following figure:

This "sensse of all perspectives" has a slight twist, leading to the keywords Elegant, Appropriate, Efficient, Integrated, and Reliable. This leads in total to 25 perspectives on the enterprise architecture, each with its own theme. For example:
  • Purpose - Appropriate : focuses on the goals of the architecture function in the organization
  • People - Elegant : focuses on the composition of the architecture team
  • Preparation -Effective : focuses on the effectiveness of the archtiecture efforts in the context of the organizational goals (mission/ vision/ straegy)
  • Performance - Reliable : focuses on the rol of real-time scoreboards / dashboards 
  • Process - Integrated : focuses on managing services in the broadest sense of the word.
For each of the perspectives the role with respect to deliverables is discussed. This got me thinking: there are a lot of architecture frameworks out there (Zachman, FEAF, IAF, TOGAF, DYA). Most of the mare "cell orriented". Different stakeholders of the architecture require different views on the contents of these cells (to put it differently: filling the framework is the 'homework' of the architecture team. The team should also prepare different views on the framework for specific stakeholder groups). It isn't always apparent how the contents of the cells are "transformed" into deliverables by the architecture team. 

Working with different views on data is relatively well research in e.g. the database community. Even more, transforming information / documents is also relatively well researched (see e.g. my dissertation Aptness on the Web). It would be interesting to see how these two fields can be combined in the context of enterprise architecture documentation. 

(Perhaps this is a nice topic for students to work on as it contains a practical component as well as a theoretical one. If you're interested, please leave a comment or send me an E-mail!)

1 comment:

Anonymous said...

Thanks, Bas - in the two years(!) since this was first published, you're probably the first person to have not only understood the 5Ps framework, and how its holism works in practice, but extended it into new directions.

One comment I would add: it's essential to note that the 25 perspectives are views, not Zachman-like cells. There is a cell-like taxonomy-framework that goes with this, but it's multi-layered, and almost every real-world entity is a composite that straddles many cells. The cells exist to assist depth-analysis, particularly for down-to-the-roots concerns such as business-continuity and disaster-recovery, but they're of limited value in themselves - unlike in Zachman, where it's (mistakenly) assumed that meaningful models can be created for each individual cell. The perspectives do each emphasise particular areas of the framework, but always look into the whole as a whole.