We created the ITA&S Framework (ITA&S-F) for the following reasons:
- To better integrate the business aspects with the IT aspects, for example, we use Business Dimensions to:
- Scope roadmaps
- Qualify metrics/KPI which are being used to monitor if processes meet their goal
- Support the Enterprise Dimensional Data Model
- Examples of Business Dimensions: Organization, Industry, Location, Role, Product, Service, Segment and Channel
- To focus on a limited number of EA artifacts since enterprise architects do not have enough time to maintain the 50+ artifacts defined in TOGAF and be able to support the EA Offerings (see EA Offerings below)
- EA artifacts are called EA persistent products since their lifecycle are very long compared with the EA Offerings which are all-time based
- These EA persistent products must be maintained in an EA tool, and the main role of these EA tools is to maintain relationships and maps of all these objects
- Since we created some new aspects such as the Business Dimension, we had to create a metamodel to support the specific of the ITA&S-F. So we decided to implement the ITA&S-F metamodel in Casewise.
- To address the difference between projects dependencies and architecture dependencies
- The ITA&S-F maintains architecture dependencies and associates versioned architecture objects to programs and projects
- This uncoupling allows to keep the architecture roadmaps totally unaffected by changes of programs/projects timelines or scope
- The versioned architecture object (representing an architectural change) is associated with programs/projects
- So when a program/project scope changes the versioned architecture object simply needs to be reassigned to another program/project
- This approach allows monitoring when silo program/project decisions prevent to reach a business objectives since all versioned architecture objects are tied to the business objectives
- This uncoupling of architectural dependencies with the programs/projects has also been integrated in the ITA&S-F metamodel in Casewise to simplify the maintenance of architecture roadmaps.
We like to see enterprise architecture groups been structured as EA Practices and consequently the EA Practice maintains an EA Services/Products Offerings available to its business customers. So it is imperative to maintain a minimal set of persistent products in order to be ready when an output is being requested. These outputs are the EA Offerings. EA Offerings have direct value to the business, it could be:
- Opinions on what the business should do to rejuvenate itself
- Plans (roadmaps)
- Business Case Support
- IT Budget Planning for applications portfolios
- Software/Product recommendation
- Assessments
- Solution Architecture Guidance
- Advice on the IT side of a Merger & Acquisition
- ...
When there is a demand for these, there is no time to get back to update our persistent EA products such as list of applications, business processes, data models, etc. This approach could be used on popular frameworks such as TOGAF, FEA and others.
The challenge is to focus on a smaller number of EA artifacts that supports production of tangible results such as: roadmaps, EA due diligence during mergers and acquisitions, support for solution architecture teams, and others.
The ITA&S-F pictures are screenshots taken from its implementation as an accelerator in Casewise.
Old articles related to Enterprise Architecture and BI TCO:
- Business Architecture : Explained
- Responsibilities of the Enterprise Architecture Lead
- What is Enterprise Architecture?
- Do you really have an Enterprise Architecture?
- Finding the right Data Architect
- DW Hybrid: Key to lower your BI TCO (Total Cost of Ownership)!
- Additional ways for reducing the BI TCO (Total Cost of Ownership)