TOGAF breaks down Architecture into the following pillars:
- Business Architecture
- Application and Data Architecture
- Technology Architecture
Phase B on our quest to establish an EA practice focuses on Business Architecture:
- Terminology: Define a set of standards so that everyone is talking consistent language (formal term here is Ontology)
- Process: The ADM (architectural development method) is open to be tuned to suit the organisation. Certainly recommended if the Service Oriented Architecture is part of the Vision.
- Viewpoints: What are the viewpoints and views that need to be addressed (who within the business has a view so that when it comes to making a decision conflict does not arise by not having analysed and measured someones view?)
- Framework: Starting to get close to some hard work now; what will the deliverables be from Architecture, what are the inter-relationships and dependencies? What rules and guidelines govern the design outputs? i.e. Must follow business principles; can break principles after following exception process A.
- Accountability: Architects must be accountable – I would love to be a fly on the wall when some of my old colleagues read this. But obviously if the practice is to be taken seriously it must be accountable, something like a RACI matrix would so the trick here I feel.
- Performance: Hand in hand with being accountable the practice needs to perform - set the targets.
- Governance: What is the process that will measure and adjust the architectural practice accountability and performance?
Other TOGAF Links:
- Introduction to TOGAF
- How to Establish a TOGAF EA Practice Part 1
- How to Establish a TOGAF EA Practice Part 2
- How to Establish a TOGAF EA Practice Part 4
- How to Establish a TOGAF EA Practice Part 5
