Enterprise Architecture is concerned about 4 key aspects:
- Business Architecture
- Data Architecture
- Application / Integration Architecture
- Infrastructure Architecture
Below is the description and the domain of each pillar, followed by key challenges faced by Enterprise Architects (EA) to outline and embed them in the organisation:
Business Architecture – is the blueprint of the organisation and draws the strategic and tactical objectives of the business. It’s very much geared towards the very fundamentals of the underlying business. Business functions (capabilities), business processes and business users are main subjects of the business architecture.
Key Challenges: understanding key business processes (e.g. billing, customer support), key players (people) and their functions (e.g. issue invoice, collect payments, triage support calls). Chances are some of the processes are incomplete, not so effective or efficient or not even defined. Same story with the functions; is there any inefficient function, overlapping functions run by different teams or any gaps? It’s EAs responsibility to identify them, design and make recommendations to correct or optimise processes and functions.
Information (Data) Architecture – Information is the lifeblood of the organisation. Key subjects of Information Architecture are source of truth of data, data entities, inter-relationship between data entities (data objects) and their cardinality (one to one, one to many, many to many). Entity Relation Diagram (ERD) is a great tool to draw data architecture of the organisation.
Key Challenges: Medium to large organisations have tens if not hundreds of data objects (example of data objects are invoice, project and customer). Chances are multiple business functions (see Business Architecture above) share one or many data objects. Here lies the challenge: what is the source of truth? A lot of inefficiencies, data quality issues and missed opportunities are sourced from ineffective data architecture. See here my previous blog-post for a real example of data architecture issue: Why do you keep charging me twice?! A real case-study of Master Data Management problem.
Application / Integration Architecture – business applications (systems) are automated solutions to enable or optimise business functions.
Enterprise and Solution Architects are responsible to draw application context including the applications (business systems) and interaction between them (integration); as well as the key components of each system.
Key Challenges: Drawing the context diagram for existing and future applications and showing the interaction between them (integration) helps the architects to understand the systems landscape of the organisation. However, in large orgs with tens of applications (including excel spreadsheets flowing around in the org!) it’s not the most straight-forward task to identify these systems and their components and understand the interaction between them (We have all seen it: Mark stores prospects and leads in his excel spreadsheet and every now and then uploads them into CRM!).
Technology Architecture – includes the underlying technology of the business systems, infrastructure (servers, network, switches, storage), environments (DEV, UAT, PROD, etc.) and security architecture (identity and access management, data encryption, etc.)
Key Challenges: Technology is frequently changing in the organisation and keeping track of the changes is one of the key challenges faced by architects and the technical team. Fall behind these constant changes and what you’ve documented is out of sync and useless!