The Open Group Architecture Framework (TOGAF)
A method to develop and manage the enterprise architecture. It is composed of multiple techniques and best practices. TOGAF advises to use Archimate as the EA toolset.
Drivers for EA as addressed by the picture approach
- Problem situation:
+ IS portfolio is complex (mostly after merger or acquisition).
+ Decentralized IS budgets
+ Low flexibility of IS & failing IS and business projects. - Challenge:
+ How to redesign the IS portfolio
+ How to reduce IS complexity
+ Diversity of IS models
+ Stakeholder are enemies - Solution: Picture approach
+ Process: pressure-cooker model, shared meaning.
+ Products: picture, fact sheets
+ Decision: multi-criteria analysis, analytical hierarchy planning.
Picture approach
- Approves, redesigns and combines system complexes (application portfolios).
- Improves business IT alignment in organizations.
Focus of picture approach
The application portfolio (IS architecture) plus relations to:
- Process architecture
- Information architecture
- Organization architecture
- IT architecture
Picture
A picture is an image of the organizational processes. This image maps out the functions of various IS applications in the processes. The fact sheets specify data and technologies.
Steps of the picture approach
- Several photo-shoots -> core process applications, documents and actors.
- Review of the photos (models) by the management team.
- Detailing the photos (models), adding fact sheets that define the following:
- Sustainability of the current and possible architectures.
- Functionality per application.
- Process support -> degree to which systems support the processes.
- Costs and benefits per application.
- Risks per application and total risk. - Freezing the photos (models) of the as-is and (some) to-be situations.
- Choosing the target EA (the to-be EA) using multi criteria decision analysis (analytical hierarchy planning).
Questions to support making a picture (PwC)
Questions regarding:
- Data and information
- Organization and processes
- Application and processes
Two main questions:
1. How many to-be pictures/architectures do you need?
2. How to choose the right to-be architecture?
+ can be done by using the Analytical Hierarchy Planning (AHP)
Tools to reduce EA complexity
- Mapping applications to business processes.
2. Quality of the applications portfolio
Mapping applications to business processes
Supports analysis of application portfolio:
- Which applications and how many are used per business process?
- Which applications are used by multiple business processes.
- Which business processes use (similar) applications (possible redundancy of applications)
To support management decisions on:
- Which applications may be phased out
- Which applications may be merged
- Prioritization of applications.
This leads to a project portfolio, and in the end changing the application portfolio.
Quality of the applications portfolio
Supports the analysis of the application portfolio:
- Technical quality
- Functional quality
- Costs
Then, decisions can be made on (e.g.):
- Which applications to improve technically.
- Which applications to improve functionally.
- Efficiency/Cost measures.
- Which applications to replace.
This leads to a project portfolio, and in the end changing the application portfolio.
3 EA approaches
- Zachman approach: focus on the right models.
- Picture approach: focus on the right modelling process.
- Practical approach: use the two models for IS application portfolio management.
Function point
A unit of measurement to express the amount of business functionality of an IS to a user. Used to compute a functional size measurement (FSM) of software.
Rules of thumb function points
- One function point requires on average 100 lines of code.
- 10.000 function points require 1 million lines of programming.
Objective complexity
What you can see:
- # Components (applications)
- # Interfaces
- # Functions (function point analysis)
How to reduce objective complexity?
- Reduce the # components per system and portfolio.
- Reduce the # interfaces (relationships) between systems
- Reduce the # functions
Subjective complexity
What you perceive as complex.
- The effort that is required to:
+ understand
+ cope with the portfolio
How to reduce subjective complexity?
- Reduce the effort to understand the portfolio -> can be done visualizing main parts and relations from managerial + IT perspective.
- Support decision making using AHP, distinguishing criteria, weights and objectives.
Roger Sessions says
There is too high complexity in relationships between organizational units and information systems.
- Anybody can create a complex architecture, takes no skill at all.
- Architecture naturally seek the maximum possible level of complexity all on their own .
- It is a complex architecture you want, then you don’t even need architects. You might as well just fire them and let the developers work on their own.
It is simple to make systems complex, it is complex to make systems simple.
Internal drivers for enterprise architecture
- Audit
- Specify management information
- Manage IT system portfolio
- Manage (out)sourcing relationships
- Guide systems development
- Preparing a merger or acquisition
- Reducing complexity
Depending on the drive the value can be determined.
Design debt
As long as you do projects that are matching the enterprise architecture standard, you’re not adding up to your design debt. Quick fixes to ‘match’ the EA add up to the design debt. Enterprise architecture to reduce design debt.
Architectural debt
Accumulated by applying a quick fix without proper refactoring.
- The debt accumulates interest over time - increasing the total cost (effort) requiring to repay the debt.
- The theory being that a system’s complexity increases non-linearly each time a quick fix is applied.
Design debt checklist
Tale-tale signs to spot it:
- No visible architectural champion.
- Lack of balance between business and IT department.
- No decommissioning strategy.
- Duplicate systems.
Why is it important?
- Geological time scales requires to make simple business changes.
- Lack of confidence that a change will actually work in production.
- Projects over-burn budget and schedule.
- IT costs to keep the lights on erode business margins.
- Clean slate ‘make or break’ programmes required to stay in business.
- Brand erosion.
Five core components of EA
- As-is: the current state of the organization
- To-be: the future state and generally the main focus of an EA assistant.
- Migration plan: without a viable route from as-is to to-be, the architecture has already failed.
- Principles: the guidelines for users of the architecture, such as ‘buy not build’ or ‘adherence to published data standards’.
- Decision log: started during the development of the EA but a key part of the ‘living’ architecture.
Architecture principles
Principles are statements of intent or purpose that:
- Support business needs and changing customer desires.
- Guide business and IT decisions and investments.
+ Principles have a rationale: why are we (not) doing this.
+ Principles have an implication: we can no longer..
- Are the foundation for business strategy and architecture.
- Reflect the vision to support the dynamic and rapidly changing marketplace.
- Reflect the vision of improved IT usage.
- Describe preferred practices for new upgraded systems.
Principles are guidelines for the construction of a (business and technical) architecture through to the physical implementation.
- They underpin our investigations when we look at architectural options.
- They are used to justify the decisions we make about the components in the architecture.
- They ensure that the architecture we define is consistent and we do not wander from our path to the goal.
-
Week 1: Introduction to the Zachman Framework33
-
Week 2: Empirical Evaluation of Models for EA44
-
Week 3: EA as a method30
-
Paper: Haki & Legner1
-
Week 4: EA as a strategy24
-
Guest lecture - Architecture with ArchiMate, Bas van Gils10
-
Week 5: Core diagrams21
-
Week 6: EA as a strategy16
-
Week 7: EA behavior theories6
