Published on April 1, 2017
I am trying to make my mind around the recent article of Simona Lovin about Business Architecture Maturity. When I read it, I could not rid of a feeling I’ve seen something very similar already. Indeed, it was an ADM from TOGAF standard. For those who are unfamiliar with this subject, it is a model of setting a practice of Enterprise Architecture created and standardised by The Open Group and focused on IT function of the organisation. As any standard like this, it has pros/cons. Also, it has its assumptions, which appear as a “grey area” – people usually do not remember or even do not know them when referring to or implementing TOFAF. Moreover, the ADM in its Preliminary step does not clearly explain where the information about the business comes from and what does Business Architecture mean in such “out-of-the-blue” business context.
In the referred paper, the starting statement is: “(employees, departments, project teams, competencies, processes, products and so on) taken together, form the business architecture of … the organisation”. If all these elements form the architecture, which enterprise elements are not in the architecture? How an architectural element differs from a non-architectural one? What, particularly, makes sense to talk about Business Architecture if it is the same as the organisation as quoted? Is this just a politically correct enumeration of all things made not to miss or “offence” one who wants to be a part of a popular “architecture” movement? If everything is “business architecture”, what is an Enterprise Architecture or it is not needed anymore?
The next statement is that Business Architecture exists in each enterprise, but in many organisations, there is no Business Architecture capability and/or Business Architecture competency. Well, if there are no capability and competency, what, actually, does exist? And, BTW, why does it exist?
With a hope that those questions will be answered in a meaningful way (i.e. without referencing to someone’s private opinion or ‘because a lot of people do so’, i.e. repeat this opinion), let’s review proposed maturity levels.
Level 1: “…the organisation has no Business Architecture competency” and “certain business architecture practices may be in place…, such practices are not governed at the enterprise level”. I think having Business Architecture without competency is from a virtual world (very popular in modern IT). Actually, an architecture either exists or not; it is not in our heads, it is real though may be intangible like we know about gravity – we can measure it, but we cannot touch it. Also, it is difficult to me to imagine how something that belongs to the enterprise, exists and operates at the enterprise level can be not governed at this level, well, at which level is it governed in this case?
I do agree with the article – every business organisation has its Business Architecture, indeed, but the given description of Level 1 clearly demonstrates that the author (and, I am afraid, the referred standards as well) simply does not know where to look for this architecture in the enterprise. A simple fact that an organisation exists and operates is the witness that Business Architecture competence and related practice exist even without formal recognition. That is, when people propose to form a team and set a Business Architecture for a business organisation, they do not bring anything that the organisation doesn’t have already.
Thus, in my model, Level 1 represents a state where Business Architecture and its practice are present in the organisation, but exist as an intuitive tacit knowledge of the business decision-makers.
To help my readers to understand my further comments, I define a Business Architect as a person who architects the business organisation. Yes, architects, i.e. makes decisions on what the business units and IT should do in order to realise corporate strategic goals and objectives. Can you imagine a construction of a building where an Architect just advises a Foreman on what to build? I cannot. Why in our businesses should we change this order proved for centuries?
We are tricked by words in this matter: we call managers of the organisation as an enterprise and those who manage development/delivery/operations by the same word – managers. However, they are quite different by responsibilities, concerns and even formal MBA education. Because of this difference, saying that Business Architecture supports business ‘managers’ is inaccurate and, actually, misleading. An enterprise-level Business Architecture does not support development/delivery/operating managers – they support Business Architecture instead via an implementation of architectural solutions.
This is the fundamental difference between the business view on Business Architecture and IT view on it. The natural separation of labour in business is this: 1) C-Executives and Board define the corporate strategy, 2) Business Architects convert it into a set of architectural solutions, decisions and requirements of what should be built, when, where and for whom, 3) the business operational management and IT realise those requirements. This also pre-determine the position of Architects of business between the Executives and the rest of Business Management.
Level 2: “… The Business Architecture competency’s mission and goals are clearly articulated within the organization. Executive sponsorship for Business Architecture has been established.” It is good when an organisation defines the mission and goal for Business Architecture. However, if we are ready to talk about maturity, we have to be clear whether a maturity model has the same implications for all organisations or not. IMO, it depends… on the size of a business organisation where Business Architecture appears in different forms. In small to medium size organisations, an “executive sponsorship” and enterprise-Governance are not needed as additional items because Executives of such organisations architect their organisations themselves, i.e. they are the Business Architects. When a company becomes bigger, Executives simply need to dedicate more capacity to the corporate strategy; they steadily delegate their architectural tasks to the experts who are freed from management duties while remaining to be Directors, Heads or Senior VPs. Since these people are not responsible for the daily delivery any more, they concentrate on what should be done to reach the strategic objectives and they task operational managers with the requirements to the Target Operating Model. Such Business Architects form a team or a group reporting directly to the C-level while the practice of this Business Architecture group (BA group) is relatively known from the previous experience.
This Level is characterised by a clear understanding of purpose and position of Business Architecture expressed via governing principles and policies. Also, the groups of Business Architects are formed on as-needed per-initiative basis as well as for researching and valuating options for the corporate business strategy. The letter is still formed bottom-up with the risks of becoming inadequate to the market changes and without the use of intrinsic architecture of the business system.
Level 3: “… core business architecture domains… have been determined” – well, in an architecture of business organisation there are no architectural and non-architectural domains ‘cause the entire organisation is the single domain the architecture applies to. However, an organisation comprises architectural and non-architectural elements presented at all levels in the organisation’s LOBs, divisions, departments and groups. On many occasions, I’ve published what those elements are and will not repeat this here.[“Architects Know What Managers Don’t: Business Architecture for a Dynamic Market“; “Business and Dynamic Change: the Arrival of Business Architecture”, chapter “How Business Architecture Enables Agility in a Dynamic Market”].
“…. The Business Architecture group, working with the business, has developed key artefacts, including, at the minimum, the capability map, the value stream map, the information map, and the organization map”. Yes, the BA group works with the business, but top-down rather than the bottom-up as the paper and, to my knowledge, the BA Guild suggests. As of architectural artefacts, they are different from the ones mentioned in the quote. Actually, they are business functionality, business information, business capabilities, capability-based solutions, decisions and capability deployment plan (CDP). These are the ones that drive the creation and realisation of Business Transformation Plans later on in the Target Operating Model (TOM).
The BA groups produce capability maps unaffectedly, as the derivatives from the capability design; value stream maps are the elements of implementation of architectural solutions that mainly work with Value Chains and the abstracts of future Value Streams; there are no information maps because information is a part of business capabilities and capability-based models and solutions. Finally, an “organization map” (the substance unknown to me) is, probably, an organisation structure that is a prerogative of Delivery/Operational business management and has to be created in accordance with the needs derived from the architectural solutions. That is, the organisational structure is how the business prefers to implement architected business solutions. Any discrepancy between those solutions and the implementation of organisation structure results in the difficulties and problems during the actual business operations.
At this level, the BA group is formed already and armed with all needed principles and policies; it supports the strategy development led by C-executives and it realises the first step of strategy implementation via business capability-based solutions. It works with Operation Management on the design of business capabilities in the areas of resources. This allows Operation Management and Business Analysts to compose and maintain the function-resource maps (capability maps). The BA group plays an advisory and governing control role during the TOM design process that follows.
Level 4: “The Business Architecture group is regarded as a strategic partner in identifying opportunities, driving business innovation, and sharing the business strategy. Business architecture practices are used consistently throughout of organisation to identify opportunities for performance improvement, incorporate such opportunities into the project portfolio, and act as a driving factor in business and IT transformation initiatives.”
Well, the BA group is never regarded as anything separate (like a partner) from the corporate business; it is an organic part of business or its brain to some degree because it is the only formal and responsible mechanism for providing agility of the business to the market dynamics at the strategic and tactical levels.
It is the core on-going duty of the BA group to identify opportunities (even starting at the Level 1) during the process of architecting solutions for the corporate strategy. BA group is not in option of “sharing business strategy” or not sharing it – business strategy is the major input in the architectural work from the day one of existence of the business organisation. At the same time, with an exception of a few special business cases, some of which are enumerated in series “Scenarios for Architects of Business”, the performance improvement is the primarily prerogative of the the delivery and operational business function; this relates to how the architectural solutions are realised.
The BA group is represented at the LOB and division levels where its members deal with internal business domains of the company. The provide a leadership and controls in the business innovations and related fund distribution. Investments in the strategy or vision unrelated endeavors are controlled. The CDP becomes mandatory for implementation for the business and technology parts of the organisation.
At the Level 4, a separation between architectural solutions and their implementation becomes instrumental. That is, an architectural solution or decision can be implemented in several different ways specific to the organisation’s culture, traditions, internal resource skills and market offerings. This assumes an intensive use of outsourcing on the service basis if internal resources appear inadequate to the strategic needs (it is a reflection of superiority of the corporate imperatives over the divisional capabilities).
Level 5: “Business strategy is articulated and realised through business architecture, with support from enterprise architecture and technology strategy…” I cannot agree more with this interpretation, though have to outline a few aspects that organically follow the concept of Architecture of Business (AoB) that has been used as the basis of my comments earlier.
So, the top level of Business Architecture maturity is reached when the BA group defines requirements that become mandatory for implementation in TOM under the governing architectural controls. That is, at this Level, Business Architecture actually merges with TOM in the AoB’s framework [see the article “Optimising a Target Operating Model through an Architecture of Business”]. This requires a significant change in the corporate culture and this is why we need to pass through the lower maturity levels to adapt ourselves to this new culture. As a result of this cultural change, the operational function of the organisation starts seeing the world via architectural eyes, i.e. using an integral view of why-what-how, and not the other way around.
Talking about levels of maturity of Business Architecture when such architecture is suggested to be segregated from the business and, therefore, requires a support from business Executives (who used to architect their companies for years), looks strange and confusing. This confusion comes from the term ‘business’ that is used in this paper in the ‘technology manner’.
In reality, business is a self-sufficient matter while technology is a supportive matter with a view on the business. This is the problem. To deal with business solutions, or/and business efficiency or/and business architecture, one has to start thinking ‘in business’. This is what the concept of Architecture of Business tries to do. I have no problems with the maturity model described in the paper – something might have it, e.g. a sort of technology practice, but it is not about architecture of the business organisation. Business is THE different world and what is good for business does not necessarily good for technology, especially if it loses its objectivity and meaning of its purpose.
HOW to ARCHITECT for DEVELOPERS 