Enterprise Architecture ROI
What are the IS quality criteria to enforce?
What are the IS quality criteria to enforce?
 | To receive the PDF format of this paper,
please just send us your email. |
In order to avoid generating an IT tunnel effect when deploying an Enterprise Architecture program, a company has to define its targeted quality criteria applied to the whole scale of the information system. Does you company can describe which IS quality criteria are targeted? First of all, these targeted quality criteria must be applied to the intrinsic value of IS (its intangible assets), not the use value (project management and SLA quality), nor the business value (financial indicators) and the software quality since this is more and IT concern than a pure IS issue. At Sustainable IT Architecture, we advocate an innovative IS foundation enforcing four generic IS quality criteria that every company should targeted: transparency, auditability, agility and mastering complexity. These criteria leverage the intrinsic value of a company’s IS Assets, it means its Data, Rules and Processes. Furthermore, enforcing these criteria also improves project management quality and software quality as shown in the figure above. |
|
Transparency
Transparency defines the ability of business users to manage their Information System assets with help from business governance functions such as: version management, authoring, querying, etc. When a company uses poor spreadsheets and usual IT databases to govern its data and rules, then the transparency is limited as governance functions are reduced, and bespoke software developments are required to deliver something usable to business users. The transparency is also in relation to the quality of the documentation. If this documentation is informal with outdated parts, then the system becomes opaque to business users. Consequently, knowledge management is poor.
Auditability
Auditability defines the ability to get a full and detailed traceability of the system from processes execution to rules and data issued by these processes. For example, in a SOX regulation, a financial data related to a grand total should be defined through rules and data used to compute it. It goes without saying that a poor system relying on spreadsheets and usual bespoke developments is unsuitable to achieve this level of auditability. Moreover, the auditability defines the ability to check that the system works in compliance with business requirements and regulations. Checking this compliance is easier to achieve when documentation is formal rather than informal and out-dated. In other words, the more the documentation is model and grammar driven, the more the conformance of the system can be checked.
Agility
Agility gives an indication of the responsiveness of a system. The targeted level of responsiveness depends on every organization. But the level of agility of IS Assets is related to the availability of real business governance functions, it means the level of transparency as defined above. For example, if adding a new commercial rule into an order entry process requires an informal writing request and a bespoke IT development in an approach of hard-coding, then agility fails. Conversely, the agility is better when using a formal business grammar that is reused to feed a business rules management system, avoiding useless bespoke and rigid IT developments. Obviously, to really enforce this level of agility, the system must also rely on a unified business vocabulary; it means a rich business data model, also known as semantic data model.
Mastering complexity
This criterion is set forth to make sure that the IT architecture is not specific to business scenarios. It means that IS foundation still remains stable whatever the complexity of future business requirements. This approach is quite different from usual IT achievement where the IT architecture is defined from detailed business requirements. Indeed, when Information System foundation is built to meet detailed business scenarios, it means that this foundation is unsustainable since business scenarios change over time. Obviously, the previous quality criteria (transparency, auditability and agility) are reliant on the company’s goals. But whatever these goals are, the ability of the IS foundation to be stable enough to absorb new business scenarios is a key objective.
Transparency defines the ability of business users to manage their Information System assets with help from business governance functions such as: version management, authoring, querying, etc. When a company uses poor spreadsheets and usual IT databases to govern its data and rules, then the transparency is limited as governance functions are reduced, and bespoke software developments are required to deliver something usable to business users. The transparency is also in relation to the quality of the documentation. If this documentation is informal with outdated parts, then the system becomes opaque to business users. Consequently, knowledge management is poor.
Auditability
Auditability defines the ability to get a full and detailed traceability of the system from processes execution to rules and data issued by these processes. For example, in a SOX regulation, a financial data related to a grand total should be defined through rules and data used to compute it. It goes without saying that a poor system relying on spreadsheets and usual bespoke developments is unsuitable to achieve this level of auditability. Moreover, the auditability defines the ability to check that the system works in compliance with business requirements and regulations. Checking this compliance is easier to achieve when documentation is formal rather than informal and out-dated. In other words, the more the documentation is model and grammar driven, the more the conformance of the system can be checked.
Agility
Agility gives an indication of the responsiveness of a system. The targeted level of responsiveness depends on every organization. But the level of agility of IS Assets is related to the availability of real business governance functions, it means the level of transparency as defined above. For example, if adding a new commercial rule into an order entry process requires an informal writing request and a bespoke IT development in an approach of hard-coding, then agility fails. Conversely, the agility is better when using a formal business grammar that is reused to feed a business rules management system, avoiding useless bespoke and rigid IT developments. Obviously, to really enforce this level of agility, the system must also rely on a unified business vocabulary; it means a rich business data model, also known as semantic data model.
Mastering complexity
This criterion is set forth to make sure that the IT architecture is not specific to business scenarios. It means that IS foundation still remains stable whatever the complexity of future business requirements. This approach is quite different from usual IT achievement where the IT architecture is defined from detailed business requirements. Indeed, when Information System foundation is built to meet detailed business scenarios, it means that this foundation is unsustainable since business scenarios change over time. Obviously, the previous quality criteria (transparency, auditability and agility) are reliant on the company’s goals. But whatever these goals are, the ability of the IS foundation to be stable enough to absorb new business scenarios is a key objective.
How to reach these four quality criteria applied to the scale of the whole information system?
To guarantee the IS to be transparent, auditable and agile while keeping a stable level of IT complexity over time, we advocate an IS foundation based on the integration of three types of business repositories: Master Data Management (data governance, semantic modeling), Business Rules Management System (business grammar) and Business Process Management. As this figure shows, the IS spine based on MDM, BRMS and BPM allows for using a project lifecycle composed with three steps: modeling, governance and execution applied to each type of IS Assets, namely data, rules and processes. |
|
The Enterprise Architecture ROI depends on the enforcement of this Information System spine, as it ensures IS transparency, auditability and agility. It enforces these three key quality criteria while keeping a stable level of complexity whatever business requirements and their changes over time. See more detailed about this figure in the fact sheet “Targeted IS/IT Foundation - Integration between data, rules and processes business repositories”.
How to apply IS quality criteria with TOGAF (open group)
When using the TOGAF’s Architecture Development Model (ADM) process, the key question a company must raise is the definition of its targeted IT Architecture. Even though TOGAF’s Requirements step is well-identified and central to all ADM lifecycle, it remains two big issues:
- firstly, TOGAF is agnostic to IT architecture, it means that a poor IT architecture can be delivered even though ADM is well-used;
- Secondly, TOGAF advocates the alignment of IT architecture with business scenarios (*). This alignment is a blind alley as business scenarios will change over time, which is not the situation of the IT Architecture; this latter should be stable enough over time.
(*) “There is a danger of the architecture being based on an incomplete set of requirements that do not add up to a whole problem description, and that can therefore misguide architecture work” (quote from TOGAF 8.1.1 Part IV: Resource Base > Business Scenarios).
To tackle these issues, TOGAF’s ADM must be completed with the four quality criteria applied to the scale of the whole information system, as defined above: transparency, auditability, agility and mastering complexity.
These criteria become the core of the TOGAF’s “Requirements” stage, feeding all other stages during the whole ADM lifecycle execution. Furthermore, along with the ADM process, intrinsic value of IS Assets, namely data, rules and processes, must be measured to guarantee the IS/IT foundation to be aligned with the quality criteria. Finally, when enforcing this recommendation, a company secures its Enterprise Architecture program by delivering an IS and IT foundation based on the use of the three business repositories, namely MDM, BRMS and BPM. This is the solution to enforce transparency, auditability and agility of the system, without any loss of control in term of complexity. To measure the intrinsic value of IS Assets along with the whole ADM process, a company may use the IS Rating Tool established by the Sustainable IT Architecture community (freely downloadable from our website). |
|
How to apply IS quality criteria with Zachman
Zachman defines thirty points of view to fully represent an information system. This is a crossing from six questions (what, how, where, who, when and why) with five levels of abstraction (scope, conceptual, logical, physical and detailed representation). It goes without saying that Zachman provides companies with a classification scheme of models but not a method to build sustainable IT Architecture. To highlight this pitfall, let’s take a quick example about a financial application empowering business users to classify financial data, and manage their version over time.
This tab shows the use of Zachman relying on a rough architecture based on spreadsheets and rigid IT developments with Visual Basic. In a next stage, the second tab will present the same application with Zachman relying on the sustainable IS/IT foundation; it means the use of business repositories, namely MDM, BRMS and BPM.
The use of Zachman with a poor IT Architecture is a blind alley. The transparency and auditability of this system are questioned as all IS assets are hard-coded without real business governance functions open to business users. Only spreadsheets with rough data entry functions are available. When a company uses Zachman with such a basic IT architecture, then the Enterprise Architecture still remains too weak to enforce quality criteria such as transparency, auditability and agility. |
|
Conversely, now let’s see the same financial application managed through Zachman relying on the sustainable IT Architecture recommendations.
Thanks to business repositories, namely MDM, BRMS and BPM, it becomes easier to enforce a model and grammar driven approach to deliver the system. The governance features brought by the MDM system allow business users to really master their data, including a secured data version management. As the level of hard-coded is reduced, the auditability of the system goes up. |
|
Findings
As explained in this paper, to guarantee the Enterprise Architecture initiative to be successfully delivered, a company needs to define its targeted IS/IT Architecture, even though TOGAF ADM and Zachman are used. The ROI of this EA initiative is then measured by computing the intrinsic value of IS Assets, namely Data, Rules and Processes. To achieve this measure, a company may use the IS Rating Tool established by the Sustainable IT Architecture community. The more the targeted IS quality criteria are enforced (transparency, auditability, agility and mastering complexity), the more intrinsic value of IS Assets goes up.
