You have your Business Architecture. Do you use it?

As a Consultant, I often ask prospective clients about Business Architecture. The usual answer is that someone already done it. They have it. They ticked the box.

More often than not it comes to me as a huge surprise. Why? Because the previous 20 or so minutes of conversation did not exhibit any presence of Business Architecture.

Wikipedia admits that “currently there is no leading definition on what business architecture is.” But is it the right question? Or perhaps the right question should be:

“How should Business Architecture be used?”

Actually, what is Business Architecture is very easy to answer. It is the part of Architecture that sits within the Computation-Independent Layers (Strategic & Business), according to Business Abstraction https://www.businessabstraction.com/data-centric-modelling/four-layers-of-abstraction/. Which suggests Strategic, Business and Functional use.

Strategic and Business Usage of Business Architecture

Business is the source of Business Architecture. However telling you how things are does not qualify as “use”.

Business uses Business Architecture when they refer to it while making Business Decision. For example, once I was fortunate to work for a CEO who placed my Business Motivation Diagram in his office. And used to to validate funding requests from direct reports.

Functional Application of Business Architecture

If Business Architecture captures the essence of what the enterprise is and where it should go, then theoretically, every significant project should be driven by Business Architecture. At least every project aligned with the business should align with Business Architecture. The same about alignment with strategic priorities, that also should be captured in Business Architecture.

Do They Use It?

If you have to ask, no, they don’t.

No Business Architecture is 100% correct and immutable. If you bought your Business Architecture a year ago, and there is nothing you need to change, it is not used.

The Temptation of Useless Business Architecture

There is a very significant advantage of a Useless Business Architecture - the developer of useless artefacts cannot be criticised. Once your Business Architecture is used, people may start discovering issues with you artefacts.

The only way to avoid such criticism is to embrace it from very beginning - in form of feedback. 

Developing Business Architecture for Use.

To ensure Business Architecture is used, it should be built in use, rather than hope that “if you build it, they will come”. That includes:

  1. Identifying the potential users
  2. Discussing possible uses with the potential usesrs
  3. Providing them with the fragments of the models early on, and getting their feedback.
  4. Ensure the process is lead by an experienced Modeller, yet
  5. Ensure that the permanent staff has increasing role in Modelling, thus enabling continuous update of the Business Architecture.

Generalisation

Perhaps, this logic can be generalised into the following:

  1. Do not buy any modelling without explanation of how it should be used
  2. Repeatedly verify fitness for the stated purpose though the course of the engagement.

However, such generic statement should not prevent us from addressing individual cases.

要查看或添加评论,请登录

Alex Jouravlev的更多文章

  • The True Face of Level 4 Process Mapping

    The True Face of Level 4 Process Mapping

    We need to have a serious conversation about Process Centricity vs Data Centricity in the face of Digital…

  • Agile, Simplified

    Agile, Simplified

    It doesn’t look like there is a good working definition of what constitutes Agile. The Agile Manifesto is supposed to…

    6 条评论
  • As-is Modelling, the Sweet Wasteland of Enterprise Architecture

    As-is Modelling, the Sweet Wasteland of Enterprise Architecture

    Enterprise Architecture is under attack. On one side, the Service Design people are “planning and organizing people…

    81 条评论
  • Agile Expectations Board

    Agile Expectations Board

    An Agile Expectations Board seeks to prevent an Agile project from successfully delivering Iterations on the way to…

  • Understanding Semantic and Property Graphs

    Understanding Semantic and Property Graphs

    Executive Summary As enterprises increasingly adopt Graph Databases, to better reflect the nature of the data, or as…

  • The Cost of the Right to be Different

    The Cost of the Right to be Different

    It is a high season for IT contracts here in Canberra, so the “Let the Hundred Flowers Bloom” anti-pattern is in full…

  • COTS or CRHMS? Understanding Full Stack of a Core Enterprise Software.

    COTS or CRHMS? Understanding Full Stack of a Core Enterprise Software.

    Commercial Off-the-shelf Software, or COTS, seems as, although expensive, a way to avoid risks and challenges…

    1 条评论
  • Some Inconvenient Thoughts about Architecture

    Some Inconvenient Thoughts about Architecture

    Enterprise Architecture should include Diagrams understood by the highest executive level to be useful. If you don’t…

  • Enterprise is the Data: Are Processes Overrated?

    Enterprise is the Data: Are Processes Overrated?

    The first thing I noticed when started to transition some of my clients from UML to OWL Ontology Modelling was that…

    6 条评论
  • Expect More Sparse Data

    Expect More Sparse Data

    One of the arguments for NoSQL Databases, along their ability to handle Big Data, is their ability to handle sparse…

    1 条评论

社区洞察

其他会员也浏览了