Human Processes: A Kiss from the Military

Enterprise architecture (EA) is all things to all people.

The MIT Center for Information Systems Research takes the IT perspective from which EA emerged, defining it as “the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model,” where “the operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers.” (www.iese.edu/en/files/6_29338.pdf)

By contrast, the Enterprise Architecture Body of Knowledge (www2.mitre.org/public/eabok/planning_an_ea/purpose.html) defines enterprise architecture as a more general integration practice, which “analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology.”

Yet another perspective is from Gartner, who see it as a tool for change management. According to their glossary (www.gartner.com/it-glossary/enterprise-architecture-ea), EA is “a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.”

One thing that most people associated with EA would have to agree on, albeit in some cases reluctantly, is that EA is expensive – not least since it's hard to do without specialized tools, which are expensive to license, complex to use, and carry a high burden for support, training and maintenance. So is there a way of achieving its key benefits without the associated cost? A process for enterprise architecture simple enough for ordinary mortals to understand and take part in?

If you look into approaches to EA, you will find the same names cropping up again and again. First and foremost, you will find TOGAF (www.opengroup.org/togaf), an agile development method for an EA. Then there is the Zachman Framework (>www.zachman.com/about-the-zachman-framework), which allows you to capture an EA as “What, How, When, Who, Where, and Why” at multiple levels. There are others, including from major consulting organizations, which often combine methodology with a schematic for data capture. However, you won't often come across the approach I'll describe here, although it has been widely used and proven to over many years to be both cheap and effective.

This is because the approach emerges from the military, and although it is not in any way restricted, most people simply don't know about it. The first version of MODAF (the UK Ministry of Defence Architecture Framework) was released by the UK government in 2005. Taking as a basis DoDAF (the US Department of Defense Architecture Framework), it added various powerful features such as capability/strategic modelling and a meta-model. Now MODAF has itself been superseded by NAF (Nato Architecture Framework), which in v4.0 provides a very robust basis for developing of both organisations and large-scale solutions. In due course, NAF will be superseded by UAF (Unified Architecture Framework) – but let's not get ahead of ourselves.

NAF includes a grid of Views (nafdocs.org/viewpoints), that looks superficially like a Zachman grid (www.zachman.com/images/ZI_PIcs/ZF3.0.jpg) but is less arcane. In a nutshell, NAF encourages the user to think in sequence about the different levels of what must be delivered. As with many methodologies, you don't need to use the entire grid. Here is one way to use NAF levels.

At Concept level, you can define the Capabilities you need to provide, accompanying Processes, and boundary assumptions.

At Service level, you can define Requirements derived from the Concepts, partition them into underpinning Services (operational areas), and define for each Service the consumers/providers, Service Level Agreements, and Timelines for delivery. At Logical Specification level, you can create Options for delivering each Service, analyze each Option, and use the analyses to prioritize, refine, blend, and select Options. A common military technique for Option analysis that could easily be applied in other sectors is TEPIDOIL+I

(en.wikipedia.org/wiki/Capability_management#Defence_Lines_of_Development) – Training, Equipment, Personnel, Information, Concepts and Doctrine, Organisation, Infrastructure, Logistics, and Interoperability.

Finally, at Physical Specification level, you can develop the organizational structures that together deliver the Services, along with the resources required to meet their Service Level Agreements and Timelines.

All the artifacts above can be described using NAF Views, and doing this allows them to be cross-referenced in order to identify gaps and overlaps, which is critical to the success of large scale organizational change and solution development. What is more, the approach is simple enough to understand that it can be understood and used by people who are not IT professionals. Tooling is still helpful, even vital, but the associated support, training, and maintenance overheads are less than with some approaches.

In relation to EA, NAF might be thought of as a way to Keep It Simple Stupid – an acronym, KISS, that emerged from the military (the US Navy) but which many people from all walks of life might appreciate a little more of!

Keith Harrison-Broninski

Keith Harrison-Broninski

Keith Harrison-Broninski is a consultant, writer, researcher and software developer working at the forefront of the IT and business worlds. Keith wrote the landmark book "Human Interactions: The Heart And Soul Of Business Process Management", described by reviewers as "the overarching framework for 21st century business technology" and "a must read for Process Professionals and Systems Analysts alike". Keith founded Role Modellers, whose company mission is to develop understanding and software support of collaborative human work processes, the field Keith pioneered with his work on Human Interaction Management. For more information about Keith, see http://keith.harrison-broninski.info.
Keith Harrison-Broninski

Latest posts by Keith Harrison-Broninski (see all)

Share

Comments

  1. Claude Patou says:

    Simple is to say no complex organization and effective, and stupid is to say discipline &/+ pragmatism.
    In attack or threat or crisis, and disfunctionment or deployment, if you have a heavy or inertial organization instead streamy, responsiveness, agile, and tactical values driven, you fall.
    If you look about Balanced Scorecard Approach military converted organizations, management is good and kept effective (simple) n’ pragmatic (stupid) but tactical values driven !

Speak Your Mind

*

Share
Share