The annual conference of the Business Architecture Guild - a BAR professional association known for the BIZBOK® Guide - took place in Brussels this year. We visited the event and learned about the importance of BAR, or Business Architecture. BAR is a relatively new discipline, which is still in search of uniformity and recognition. What is Business Architecture exactly and how is it implemented in practice? What is the added value of BAR and how can you convince the C-level management of this? We gathered different opinions during the conference and examined the best practices.
The most commonly heard buzzwords at the conference were “capability map” and “value stream”. Every speaker juggled with these terms and it seemed as if everyone had a different interpretation of these terms. However, there is agreement over the fact that the objective of BAR is to create structure for strategy execution. This implies that BAR can only be applied in sufficiently mature organisations, since a clear, transparant strategy is one of the minimum requirements (which is not always easy to achieve in practice).
This usually depends on the company, the background of the Business Architecture in question and the maturity of the organisation. There are different types of opinions and practical cases. BAR is usually determined at the strategic level. But often it is also, or exclusively, determined at an operational level, because Business Architecture is primarily IT-driven and mainly developed by ex-Business Analysts (and hence, it is often process-oriented or specifically driven by IT processes). However, a clear, transparent strategy is a prerequisite for an effective BAR. In my opinion, a good working method is to follow a top-down approach, starting from the company's strategy and objectives and working downwards to the operational layer.
There are different levels in Business Architecture and capability maps therefore often contain multiple levels of granularity (from L0 to L5), where the first level is the strategic level and the last level sometimes goes as far as the Infrastructure level. There are many Business Architects that struggle not just with this granularity but also with how to link capabilities to the organisation on the one hand, and to the applications they work with, on the other. There is a school of opinion that states that concepts cannot be further sub-divided into other concepts and that establishing a one-to-one or one-to-n link is simply not possible since the real world is far too complex to be abstracted in a model. The other, more pragmatic and business-oriented school of opinion argues that this is possible and therefore, links capabilities to departments and their applications. This discussion was continued further during the Expert Panel on sector reference models.
How are reference models developed? How can Guild members set up these models and then from their ivory towers "impose" them on thousands of companies within e.g. the finance sector? Capabilities are often equal across various companies within a sector, but how equal are they precisely and to what level of granularity? In my opinion, this can never become a true reference in the sense of an ideal picture, but it is a starting point fot setting up BAR for an immature client. The main advantages of such reference models are time savings, a checklist and a shared vocabulary.
The key question of the conference was: what is the added value of Business Architecture for an organisation? This was met by a thundering silence. In fact, this is one of the main areas on which the Guild needs to work. Usually, BAR falls under IT, where a group of people make models that nobody understands or reads. Whereas added value is all about making the organisation transparent and comprehensible to all and serving as input for a roadmap of actions/projects for executing strategy. But above all, to clearly demonstrate the areas that require investment and those that don't. What are we working on and what should we be working on? The senior management's interest is aroused when the added value is linked to budgets, financial and cost-benefit analyses. There is a need to move away from models simply for the sake of making models to providing insight into "why" and "what".
For example, a Dutch banking group even links story points to their capability model and heat maps are created (what is it that we really need to work on at present?) by the different departments with the help of a useful app. Business Architecture descends from its ivory tower and involves colleagues in the effort: a process of co-creation in order to create interest, transparency and hence, added value. In many multinational and other companies, the recognition of BAR has been an uphill battle of several years. The biggest obstacle was proving the added value of Business Architecture. A major breakthrough in most practical cases can be achieved by linking the models to elements that are important to colleagues, subordinates and management and discussing this with one another. BAR requires courage, because it is something new which provides insights that can turn everything within the organisation on its head.
The change management aspect should nog be underestimated, since there are many barriers to bridge. Even right up to the top. After all, the lack of a clear strategy is a C-level matter and often arises from the fear of being accountable or from complete ignorance about what the company is currently doing or where it should be heading. BAR can play a supporting role in this. This framework can provide a more detailed structure for governance, portfolio management, innovation, process optimisation, product development, etc. An interesting example of this was how, at United, BAR succeeded in breaking free of the traditional organisation and creating added value both internally as well as for the customer. There is one owner - possibly a business owner - per capability (e.g. flight order registration) who is responsible for matters related to organisation of processes, applications, infrastructure etc. This creates a single point of contact for all kinds of issues faced by the client (as a result of which the traditional application SLAs are put under pressure and measurement can actually take place based on the client). The strategy of becoming more customer-oriented is translated into practice by applying BAR throughout the organisation.
The next task for the Guild is to make customer-oriented thinking a part of BAR. Several companies, mainly from the finance sector, are working on customer journeys, personalities, value propositions etc. How does this relate to classic value streams and capability models? Here too, there appears to be a dilemma. Is this the part of the operational aspect or is there more to it? I believe that, even while abstracting the process to the L0 level, one must not lose sight of the client and the fact that gaining an insight into the client’s needs forms the rationale for a capability, department or project. The basic concepts of the Enterprise Architecture course (i.e. knowledge, organisation, process, tools and customer) often came to mind. All these elements must be covered under BAR, so that it is complete within its level of abstraction.
There was also discussion about the position of BAR within Enterprise Architecture, or EA, since there is no unanimity in this regard. Only one speaker ventured the opinion that EA consists of BAR, information, application, infrastructure as well as security architecture.
So, what are your thoughts about Business Architecture? Does your company make full use of BAR? Please tell us in the comments below.
Also, if you like to know more about Business Architecture and Enterprise Architecture, please join us at our Digital Accelerator, where we give you and your digital knowledge a boost!