The Fragile to Agile Enterprise Architecture Framework
The first question to answer is why did Fragile to Agile develop its own framework rather than use an existing framework like Zachmann or TOGAF? The rationale was essentially two fold. Firstly, in our experience none of the existing frameworks resonate with non technology people. The general reaction of business executives to Zachmann or TOGAF is akin to “ah, that’s an IT thing; I don’t need to understand that”. This is a poor starting point for a discipline that must be engaged with the business from beginning to end to be successful. In contrast we find that our framework is more easily understood by non technology people and also crucially reinforces the message that Enterprise Architecture is not just about IT, it’s about the whole enterprise, with IT being just one component of that enterprise.
The second driver for developing a new framework was that the existing frameworks cannot easily be embedded in the process of designing and delivering change, never mind form the basis for a new, architecture driven, approach for this process. Furthermore, we were looking for a framework that would support all aspects of Business Transformation, and that the same framework would support Strategic Planning (turning Strategy into Execution), Conceptual Design (from project initiation to business case), Logical Design, and Physical Delivery (SDLC). The Fragile to Agile framework can and has been successfully used to re-design each of these elements of the end-to-end change process.
The following picture is a high-level view of the Fragile to Agile Enterprise Architecture Framework:
Fragile to Agile Enterprise Architecture Framework
The framework is essentially a matrix with domains of design as the y-axis and levels of design as the x-axis. The domains of design are broken into four categories; Business Intent, Business Design, People Design and Technology Design. The framework was deliberately designed to be extensible so additional domains of design can be added (or removed) to suit your organisation’s needs. However, it has been a number of years since we have found it necessary to add any additional domains of design, the last addition being User Pathway Analysis. One tailoring that is common is for government or non-for-profit organisations to change the domains for Business Intent, often adding whole-of-government outcomes.
EAF Domains of Design
The following section gives a high-level description of each of the domains of design:
Business Intent
Financial Outcomes
Understanding the key changes in financial outcomes intended. This includes regulatory outcomes where the impact of not doing the project is a negative financial impact.
Customer Experience
Understanding the key intended changes in experiences for Customers.
Partner Experience
Understanding the key intended changes in experiences for Partners.
Staff Experience
Understanding the key intended changes in experiences for Staff.
Business Design
User Pathway Analysis – “How the users interact with the organisation”
Understanding the user experience associated with interacting with the organisation. Does the user have the necessary information available at the time we are asking for it? How aligned is the system with the users natural way of thinking, i.e. Natural systems based design?
Business Capability Model - “What the business does”
Understanding each of the major business capabilities that are required and the key design principles of each that will need to be adhered to if the Business Intent is to be met.
Business Process Design – “How it does it”
Understanding how existing business processes are impacted, and/or what new business processes are required. The way services provided by the organisation, partners etc. are combined to deliver the desired customer/partner/staff experience.
Information Architecture – “What information it needs”
What information does the organisation need to service its customers, partners and regulatory bodies?
Channel Design – “How it delivers it”
Understanding key changes to Channels being supported or which products are supported via existing channels.
Business Security Design - “How it secures it”
Policies; POI/EOI procedures; Consistent authentication rigour across channels; support processes for password resets etc.
People Design
Role Design
The skills, procedures, standards and work instructions needed to perform a given role.
Job Design
The bundling of (wherever possible like) roles to create jobs.
Workforce Design
Organisational structure. Where jobs are located. The levels and number of jobs needed.
Technology Design
Solution Architecture
The solutions, built and purchased, we have/need. The key functions that each application performs. This is sometimes referred to as an organisation’s Applications Portfolio in some Architecture Frameworks.
Integration Architecture
How the applications interact with each other. How the applications collaborate to deliver the business intent. Level of coupling, messaging etc.
Construction Architecture
Describes how applications are designed and built to meet the IT objectives of the Initiative/Project. Covers the application layering etc.
Data Architecture
The information we collect and store. How we optimise our data and how we reduce duplication and redundancy.
Security Architecture
Implements Business Security Design. Includes all functionality related to Authentication, Authorisation, Identity Management and non-repudiation. Includes Firewalls, Network Intrusion Detection, Anti-viral tools etc.
Communications Architecture
The actual networks that transmit the data. Includes the LAN/WAN, any dedicated connections the organisation participates in, e.g. VPNs.
Infrastructure Architecture
In the main hardware but also covers software that is “close to/tied” to the hardware, e.g. operating systems.
Operations Architecture
The solutions used to provide Service Desk, Incident, Problem, Change, Release, Service Level Management etc. Includes Disaster recovery; backup and recovery; Instrumentation monitoring; QoS assurance etc.
Solution Development Architecture
How will the solution be developed.
Solution Testing Architecture
How will the solution be tested.
The following diagram shows the relationship between the domains of design, focusing on the technology domains:
Fragile to Agile Technology Domain Relationship Diagram
Levels of Design
The levels of design are essentially ever increasing levels of detail, starting with strategic design through conceptual design to the logical and physical designs. While these general levels of design have been around for over a century and predate Enterprise Architecture by some way they are still poorly defined even outside of the EA discipline. This is primarily because they are difficult to describe beyond what is already implied by the dictionary definitions of these words. The below attempts to provide more clarity of how these terms are used within the EAF.
Strategic Design Level
The strategic design level articulates a high-level abstract view of an organisation’s business strategy (intent) and the consequent set of principles for each domain of design that need to be adhered to if the outcomes are to be achieved.
Conceptual Design level
The conceptual design articulates a concrete view of the desired project’s intent, the business model, people and IT systems. This level of design is targeted at senior management within the organisation. It is analogous to the elevation and floor plan views that building architects use for their customers when discussing the conceptual design for a building.
Logical Design level (all layers)
The logical design describes using a more formal notation and design tools a more detailed design converting business intent into detailed requirements; the high-level business design (“clean-skin” business processes and capabilities) into a more detailed design (fully defined business processes and services); the high level people design into detailed roles and responsibilities and the high-level technology design into detailed system models. Continuing the building analogy, the logical design is the equivalent of the blueprint that adds the detail needed by various specialist contractors to perform their function in building the structure. Similarly, logical design adds the details that clarify the conceptual design, making it precise, unambiguous and actionable.
Physical Design level (all layers)
The physical design describes using technology specific formal notation and design tools the “nuts and bolts” level design converting detailed requirements into Business Implementation plans and Benefits Realisation plans; the detailed business design into user guides, procedures, standards and work instructions; the detailed people design into training and potentially recruitment plans and detailed system models into domain specific models and code. Continuing the building analogy, the physical design is the equivalent of the “bricks and mortar” level of design: how many bricks do we need; how deep do the foundations need to be, how will the rafters in the roof be arranged etc.
