In this post we examine why a company would have issues with creating an Enterprise Model and what it would take to create it.
Businesses demand insights into how business capabilities are realized including information about processes, applications, physical infrastructure and other components of the enterprise’s entire ecosystem. That information is expected to help business executives make decisions to advance their company’s capabilities while eliminating any inefficiency and waste. The quest for this information breeds an idea of a holistic “Enterprise Model” which would enable prompt decision making.
The concept of “Enterprise Model” is far from new. However, industry surveys show that most of organizations have not implemented the model or have rudimentary and inefficient surrogates. In addition, although some companies may recognize the need for this type of model, established traditions / customs become an additional hurdle. For example:
The model is seen as something bearing high cost for its production and maintenance with very low prospects of any return on the investment.
Project work is considered as a higher priority over something less urgent, such as an Enterprise Model. It is assumed it will take time to create a model while numerous projects will keep making changes to the model while it is being created. That is clearly a path to failure.
It is unclear who would create and maintain the model. While it may be logical to expect that the Enterprise Architects would create it, the architecture practice may not be ready to take ownership of the model due to capacity constraints or other reasons.
The model may be envisioned as a collection of design documents, Visio diagrams, PowerPoint presentations, etc. It is hard to imagine a process which would keep a massive library of documents up to date and which would accommodate endless review and approval meetings done in a traditional way, and so on.
These common beliefs rise out of misconception and lack of information. For example,
An Enterprise Model is, essentially, a database, not a document library. The architects use a modeling language to create and present the data. The use of the modeling approach helps drive a fundamental shift in understanding of how the output of architect’s work can add value, and it leads to a drastic increase in overall architecture team’s capabilities and performance;
It is unnecessary that the model must be ultra-precise. It should be sufficiently detailed to support various types of searches and analysis. Its precision and coverage may grow over time.
It is unnecessary that the Model should appear at once as a result of a dedicated investment made upfront. Quite the opposite, it is easier to start from an empty repository and grow the model as a by-product of various activities that are already underway within the organization.
Although multiple projects may produce an avalanche of information, it is possible to formulate that information into a model. With the right framework in place, the model will appear, grow, and eventually provide numerous benefits to a large community of its consumers;
Therefore, the challenges that an organization may identify when considering the adoption of an Enterprise Model may reveal inherent inefficiencies that may require resolution, rather than actual difficulties associated with the model’s adoption.
Early model’s adoption experience shows that the average reaction to this concept is very much like when business analytics were first introduced more than a decade ago. The model is, essentially, just another type of data that an organization needs to learn how to collect and use. What needs to happen now is that the approach which proved to be effective for business reporting and analytics should be re-applied, extended and spanned across the entire enterprise to include the processes, applications, physical infrastructure and everything else needed for answering the new type of questions. For example, instead of only capturing information about business transactions, the new information collected should include details of organization’s capabilities that enable execution and processing of those transactions.
The model may be produced with a combination of different means such as visual modeling and automated data uploads. Both methods of creating a model are shown on figure below:
The model can be initially loaded with data originated from various sources:
Content databases;
Spreadsheets;
Networks;
Legacy architecture artifacts;
Corporate social media, etc.
This data upload may require specialized tools. Uploaded data may be further utilized in visual modeling and in the production of new views and reports. Then, the same tools can be used for continuous model updates with new information.
Although the described concept of data collection and management look very familiar, the approach which would allow production and maintenance of this data is still new. That approach requires an architect’s involvement when describing how the organization is designed, how it operates and what means are used to support those operations. Those descriptions collected systematically in a formal way are the data that comprise the model.
In order to produce the model, at least the following points need to be implemented:
Setting up an Enterprise repository. This is where a holistic and cohesive model of the enterprise or the Big Model would reside. Not a document repository but a live database where all necessary information could be collected, validated, connected, shared, and available for searches.
Adopting modeling languages and professional tools.This will make the idea of building and exploiting the model of the enterprise an achievable reality. Multiple vendors demonstrate their advanced tools for architects. This looks like switching from text editor-based programming to the use of advanced development environments, source code repositories and performance tools. This also requires competent architects who would work differently. The architecture team needs to learn how to build a working model of the enterprise, which is like the way a software development team usually works to collectively produce working code.
Refining the role of Solution Architect (SA) as a modeler.Architects should be equipped with the right skills and tools, while the leadership should be ready to support the role with the necessary organizational changes.
Refining the role of Enterprise Architect as a custodian of the model. While SA does much of the leg work producing and updating the models, the EA is in the business of accepting the models into their custody for permanent care. Before a change to the model gets accepted, multiple rules may apply. Architecture governance takes responsibility for policy enforcement and keeping the model alive, up to date and useful across the organization.
Setting up an Architecture Development Workflow as part of the delivery process. Not necessary you need to build the entire model at once. Introduction of an Architecture Development Workflow would put the model to the evolution path, and it will evolve to a reasonable maturity level within a few months without any additional funding. The workflow ensures that the information is efficiently collected and processed with the participation of key stakeholders. Therefore, the model of the enterprise would stay alive and continuously evolve.
Institutionalizing Subject Matter Experts (SM). SME institutionalization is required to help distribute the burden of validating and processing of a large inflow of information. Institutionalized SME, which means ‘assigned and enacted’, are the owners of competencies and it is their responsibility is to consult other parties and keep the information within their area of expertise up to date.
Setting up a dedicated Knowledge Base. Companies often use Wiki in conjunction with a document repository as knowledge bases. In our vision, and this is what is often missing, the knowledge base usage should become part of the process to define and activate the links between the elements of the model, related knowledge items and the people who own the competencies.
Setting up a Governance body for managing the model. Model’s management requires governance. This is different from a formal approval body in a phase-gated process where Architecture Review Board or Committee reviews submitted architectures based on short presentations and checklists. Model governance is done through a technical committee usually called Architecture Working Group (AWG). It usually an architecture forum established for addressing practical issues arising during model’s production and maintenance. The activities may include the initial brainstorming, peer reviews, design strategy assessment, design quality control, reuse considerations, etc. The AWG-appointed council is responsible for design acceptance and raising escalations when the council does not have enough authority to resolve an issue.
Once the architecture practice is set up, it may take 2-3 projects to start seeing how the model would begin to take shape and add value.
Learn more
Comments