How

Address Issues Through
Training, Standardization and Tooling

How

.

Our approach to Architecture Coherence could be described in 4 steps.

Assessment

Standards

Modeling

Putting It All Together

A couple of concepts to establish beforehand

Enterprise IT-wide processes. These are the processes around the creation of the services that will generate value for users. Think of it as the “production line” producing cars.
The production line is one thing, the products (cars) are a different entity. The 2 are related but have clear boundaries and purposes. This is what IT4IT provides, a template for what is needed in the most generic case: (Strategy to Portfolio, Requirement to Deploy, Request to Fulfill, Detect to Correct).

The products or services provided to users. These are the products or services that will generate value to the users. In the analogy above, they are the cars, SUVs, Convertibles, Trucks created by the production line. In the IT world you can think of them as the services provided by a bank: to transfer money, to provide balance reports on the money you have deposited, to provide reports on the interest you are paying on a loan, or to provide loans in the first place.

Business Architecture. This is the architecture domain that deals with the business processes that realize the enterprise IT-wide processes and/or the products/services. Business Analysts are contained within this domain and also Product Managers.

That being said, the steps below outline what Architecture Coherence would do for its clients.

Assessment

First, we move into asses the level of models/schematics representing of the actual enterprise IT-wide processes, compared to a baseline template provided by IT4IT / ITIL and the actual solution/services flow describing the value.

This assessment would be driven by Architecture Coherence; by both a PM and an Enterprise Architect who is fluent in Business Architecture and IT Architecture. Consequently Architecture Coherence would connect with their analogy on the client’s corporation. Either the same roles (a PM and an Enterprise Architect) or similar (BAs and Solutions Architects).

Outcome

Reports/Models describing assessment.

Standards

=

Establishing Common Notation

Based on the assessment on item 1, we proceed to describe and agree on a common notation. The first idea behind Architecture Coherence is to use a single common notation that can represent both Business Architecture. That common notation is called Archimate. Architecture Coherence will provide awareness and basic training to the proper roles/teams.

=

Establishing An Analysis Framework

Based on the assessment on item 1, we proceed to describe and agree on a common analysis process/framework. The second idea behind Architecture Coherence is to break down any IT-Process or Service into 3 main layers: Business Architecture, Application Architecture and Technology Architecture. This analysis process decomposes any IT-Process/Service into 3 parts; allowing to then cater the highest level analysis to business/product teams, the next level to application development teams (including QA) and the final one to application support teams. This is where TOGAF comes into play. Architecture Coherence will provide awareness and basic training to the proper roles/teams.

Outcome

Basic concepts, notations, frameworks understood by proper teams: Biz, Dev, QA, Ops.

Modelling

Having done an assessment and having done basic training to proper teams within our client’s companies. We then proceed to model following the standard notation and the standard analysis framework.

=

Modelling existent IT-Processes/Services

Architecture Coherence will drive/facilitate the modelling of current IT-processes/Services. The main purpose of this step is to understand with a clear modelling notation where things are as of now: How do current IT-Processes/Services look like today at the Business Architecture level and how are they realized in the Application Architecture level ie which application component realizes a business process(Say Ticket Management) or a Service (Say health-care claim processing). Finally, how are the IT-processes/Services realized by the Technology Architecture stack ( Service-now or MS CRM, or a home developed application using IBM Websphere). This step will occur in iterations following an agile approach.

=

Establishing An Analysis Framework

Based on the assessment on item 1, we proceed to describe and agree on a common analysis process/framework. The second idea behind Architecture Coherence is to break down any IT-Process or Service into 3 main layers: Business Architecture, Application Architecture and Technology Architecture. This analysis process decomposes any IT-Process/Service into 3 parts; allowing to then cater the highest level analysis to business/product teams, the next level to application development teams (including QA) and the final one to application support teams. This is where TOGAF comes into play. Architecture Coherence will provide awareness and basic training to the proper roles/teams.

Outcome

Archimate models describing the current state of 1 or more IT-Processes/Services.

=

Modeling future IT-Process/Services

Services that are needed but have not yet been realized. Architecture Coherence will drive/facilitate the modelling of future IT-processes/Services. The main purpose of this step is to understand and model the companies’ vision of what they want to do in the future. There will be multiple visions coming from different teams: Business, Product and Technology. Architecture Coherence will drive/facilitate the merging of multiple visions into a workable model that is agreed upon by different teams. This step will occur in iterations following an agile approach.

Outcome

Archimate models describing target state of 1 or more IT-Processes/Services.

Putting It All Together

After models have started to be worked on it is important to understand that the models will be live as they will be modified in time. Finally Architecture Coherence will describe the way teams ( Biz, App, Ops) will use the models to communicate among themselves and execute implementations. No more systems described in prose, no more 3 different kinds of notations. As time moves forward, ambiguity in communications will tend to decrease. The repository containing all models becomes a company’s library. All teams involved in a given initiative will actively participate in modeling checking IN/OUT newer versions or new models altogether.

Issues will arise as the company moves forward creating new IT-Processes/services or modifying their existent ones, but the flow of information among teams and more importantly the quality of the information (models) will increase exponentially across teams. As such, the accuracy of the decisions made based on the models will also improve.