With a few standards such as the Archimate modeling language and The Open Group Architecture Framework (TOGAF) taking such prominence, it’s easy to forget that The Open Group proposes and manages a fairly group of other frameworks and standards, quite apart from its other work presenting webinars and white papers.
One interesting new framework that The Open Group has released at the preliminary stage (meaning that it may be revised before being finalized, perhaps due to feedback from the field), is the Open Business Architecture, or O-BA. It’s being released in three parts; part 1, which I’ve talked about before, serves to set the scene, including laying out the case for business architecture, discussing necessary viewpoints and exploring both horizontal traceability and vertical traceability. Part 2 is now published as a preliminary standard, and apart from a high level list of techniques (something that part 3 will apparently focus on in depth) it covers two main areas – a capability map for business architects, and a high-level plan of activities for the steps involved in business architecture transformations.
The first is very interesting to me, as it is very much a case of ‘eating one’s own dogfood’, to borrow a favorite phrase from Silicon Valley. Just in case the phrase is unfamiliar to anyone, eating one’s own dogfood is when you use the product that you produce. In other words, a common activity of business architects is to identify a capability map and assess the organization’s strengths against that capability map, but an individual (like a business architect) has capabilities just as much as an organization – so if the technique is valid for the client or employer of the business architect, then why not for the business architect themselves?
The capabilities themselves are detailed to an interesting degree, listing what inputs each capability acts on to produce what outputs, plus the different skills and techniques that form each capability. This does open up the old chestnut as to the difference between capabilities and processes, and I wonder if all the capabilities listed are truly capabilities (of course, one counter-argument could be that in that case, each capability is simply the capability to execute the associated process). I certainly think that this attempt to identify the components of the capability is a very desirable approach, and I wonder if it will appear among the techniques of part 3.
The activities map is structured according to stages in an engagement – no surprise there, and the stages (and associated business architecture activities) all make sense. Outputs from each stage are listed (e.g. ‘Capability transformation impact’), and it would be interesting to see if there are plans to provide a definition of the structure and/or contents of each of these outputs.
As with part 1 of the O-BA, part 2 offers a number of valuable observations to help business architects, and it’s definitely going to be a valuable resource, but I suspect that we’ll see a number of revisions once it’s had some use by the wider community. In the meantime, any parties interested in business architecture would do well to have a look at the preliminary version.