A Brief Review of BA approaches: IBM's RJ10451

Saturday, April 17, 2010 |

IBM’s RJ10451 was published in August of 2009. Titled, A Comparative Review of Business Architecture, it is well structured and thorough, using parameters that are reasonable and not specific to any business domain and therefore generic.

That the article includes notations such BPMN, Archimate and meta-model type standards such as OMG's BMM and BAWG surely means the space is nascent. However, we can all use the article’s structure to think about how we're focusing our own BA. Is your approach strategy? Operations? Business Network focused? Revenue & Performance Model centric?

Also part of the article’s structure is what each approach says about and defines and markets the following:
        •        Conceptual Model
        •        Methodology
        •        Tools
        •        Service Focus

As of this writing the only part that SenseAgility lacks is a comprehensive single tool. All but one of our execution models is based on standards that any UML/Archimate tool can provide. Of course we also use spreadsheets and presentation software.

As far as the article itself...

McDavid's Business Concepts class model is a good example of how a class model can be used to describe a BA domain. SenseAgility’s is considerably more complex as well as more detailed but McDavids was created in 1996 and not 2009-2010.

IBM's Component Business Model is typically heavy but contains generic business capabilities that could be used to populate a generic SenseAgility BA capability map.

Interestingly, out of the four BA domains Strategy & Structure, Business Network (customer/supplier), Operations and Revenue & Performance Model, the one least covered by any of the existing BA approaches is Revenue and Performance Model. This is where SenseAgility's approach shines. Our CBA’s link directly to capabilities and provide input to our Road Map deliverable.

Happy sailing.

What Business Architecture is Not

Thursday, April 8, 2010 |

There’s a rising crescendo of chatter about business architecture lately, so much so, that recruiters have caught on and are starting to bastardize the term to attract all manner of talent to their open positions.

Of course there’s a long list of what Business Architecture is not. It is not technical architecture but you knew that right? But did you know that it is not BPM or ETL or SOA? Nor is it setting business goals for your company. Business Architecture is not Enterprise Architecture as it is currently practiced or as it is currently allowed to practice in some companies (don’t talk to the business).

Business Architecture is not about only one thing. You can’t gain skill in a tool and therefore have the ability perform Business Architecture. You can’t even necessarily perform the function of Business Architecture if you’re a successful Enterprise Architect. You might have a better chance or you might not. Being multi-disciplinary means being able to think on many levels and in many domains simultaneously.

Like Enterprise Architecture and business it is multi-disciplinary. It has to be because successful Business Architecture ties things together. The things it ties together are things like Business Processes, Organizational structure and tasks, Technical Architecture and Risk Management.

Now you may be thinking that if you’re a requirements analyst that you’re doing Business Architecture. Good thought but that’s not quite it. As a requirements analyst you’d be analyzing requirements for a particular aspect of a technology decision that’s already been made. Business Architecture comes before those decisions are made and in fact it helps people (executives) make those decisions.

In short, Business Architecture informs decision makers about the complex road that lies ahead and in that take on Business Architecture is implicit the ability to provide relative valuations on the specializations that the organization has or that that organization needs in order to fulfill its goals. So yeah, you need technical chops, process awareness, an understanding of how organizational function can be broken down and the importance of risk management and security in those decisions, and, oh yeah, you need to link all that to business objectives and business goals (which are not the same by the way).