Stands for Architectural Development Method
--> ADM gives us a structured, step-by-step approach to develop & manage enterprise architecture.
ADM is an iterative model / a cycle. We'd revisit and refine the architecture in each cycle, This means we're becoming adaptable to dynamic business scanerios.
--> ADM provides us with a "holistic" methodology to designing, planning, implementing & governing EA. 👍
ADM comprises 8 phases:-
--> Preliminary Phase:-
- We're establishing the architecture framework and principles
- Setting up some governance structures ( GS would oversee if the architectural implementation aligns with the business)
- Plus, setting up the Organisational Capability - The Org. structure, roles & responsibilities we'd need to deliver successful projects. ( Capability Assessments )
What exactly are we doing here?
We're laying the groundwork for our architecture project Once we've defined the principles, the frameworks, the scope, we've set the stage for subsequent phases of the ADM. We're ensuring that the organisation is actually ready for architectural development. 👍
--> Phase A - Architecture Vision:-
- Define the high-level aspiration --> The architectural vision
- Request for Architecture Work would be issued by the sponsors (This triggers of the architectural development process)
- Seeking Approval from stakeholders (Support from key players)
- A clear Statement of Architectural work that would be delivered in the iteration of ADM
What does this mean?
We're outlining the high-level vision for the architecture. This vision should align with business goals. This provides "clear direction" for us to proceed with the later phases of the architecture. During this phase, the sponsors issue "Request of Architecture Work" -- to formally initate the process of architectural development. Also, stakeholder buy-in and support --> their approval is sought to ensure we've got the support of relevant parties
--> Phase B - Business Architecture:-
We're defining the operations in an organisation, while focusing on --> Business processes, org structure, roles and "capabilities"
I'll breakdown the jargons we've used -->
Business Processes :- Core activities that produce "value" for the organisation. They define how tasks are carried out to achieve business goals.
Org. Structure :- Hierarchy and Relationships between departments, teams etc
Capabilities:- Abilities slash competencies required to deliver successful projects
KPIs :- These are the metrics to measure the performance - to "quantify" the success of business activities
For those who're new to the business terminology:-
What exactly is the difference between business processes, goals and objectives?
By business processes, we mean the "activities" performed to produce value --> drive the organisation towards a streamlined business growth. Business goals, on the other hand, refer to the "aims" that an organisation strives to achieve; and this guides an organisation's activities & priorities 👍
Key Activities that're a part of Phase B :-
1 --> Developing a Baseline Business Architecture:-
We're evaluating/ assessing the current business processes, org structure, roles and capabilities. Plus, getting it documented, (It'll serve as a baseline or reference point for comparison with the target architecture)
2 --> Defining a Target Business Architecture:-
We'll then establish a vision for the desired future state of the Business Architecture; and identify the capabilities/ competencies needed to achieve it
3 --> Gap Analysis :-
Identifying the gaps/ inefficiences in the current Business Architecture, analysing the differences. Also, determining which gaps need to be addressed on priority
4 --> Having a detailed implementation plan/ action plan laid out:-
This means having a detailed roadmap in place to move from the Current Architecture to the Desired/ Target Architecture. Making sure we're aligning the business architecture with the Data, Application and Technology Architecture.
Plus, sharing the business architecture plan with the Stakeholders for a "clear communication"
--> Phase C - Information Systems Architecture:-
- Comprises both Data and Application Architecture aspects, sequence doesn't matter through
Flow of activities in the BDAT phases, is pretty much predictable.
We'd first start with defining the baseline architecture; Then, develop the target architectures. Perform a gap analysis, to analyse the differences between the reference and target architectures. And accordingly, we'd build out a detailed implementation plan - a roadmap to provide strategic direction to the activities plus setting their priorities. These need to be in lines with the "overarching" objectives of the organisation.
Plus, incorporate some stakeholder management - communicating the plans to ensure their needs are catered to Documentation, for a crystal-clear documentation
Data Architecture:-
Focus :- Describing the Data Model, Emphasis is on Data Management & Governance here- ensuring it supports and aligns well with the overall business and IT infrastructure.
💡 Intent is to ensure the quality, security and accessibility of Data --> This means having strong & robust Data Governance Policies and procedures to control the flow of data
Key Activities that encompass this phase:-
1 --> We'd first define what's called a "Baseline Architecture", That's through analysing the current state of data --> the data sources, structure, models & flow of data
2 --> Next, develop the vision of the target data architecture - We'd be developing physical and logical data models, have some data flow diagrams created
3 --> Identify gaps, from a data standpoint, prioritise changes considering 1 --> Feasibility of changes, and 2 --> Impact on the business
4 --> We'd then have to involve relevant stakeholders within the data domain, keeping them informed, seeking their formal approval (We need to ensure senior leadership buy-in and support at every stage...)
5 --> Data Governance --> The core of DA, We need to define and implement Data Governance Policies, --> procedures around data quality, consistency and security
6 --> Plus, establishing best practices around data --> Data Management. Specifically, practices around data storage, retrieval and maintenance
Importance of Data Architecture:-
--> The data management practices must support & align with the organisation's strategic objectives
--> We need to establish some standards for data quality, consistency --> Make sure the data is accurate, clean and "transparent" --> accessible to all
--> Making sure there's an efficient utilisation of data sources at hand (Answers the question - "Do we have any scope for improvement for our current data management practices?)
--> Ensuring we're compliant with regulatory standards (From a data protection standpoint)
Now, let's move on to the Application Architecture
What do we mean by "Application Architecture"?
It means "developing the application blueprints" --> Developing the applications, their interactions, their integrations + their relationships to the core business processes
A generic procedure, or rather a flow of activities that're a part of the application architecture phase:-
💡 We'll first start by assessing the current functionality, the interactions plus the relationship with the core business objectives. (Defining our baseline application architecture)
💡 Next, we'll have some application component models, interaction models, and data flow diagrams created -- "developing the target application architecture" - our desired application architecture
💡 A quick gap analysis --> Figure out and prioritise the gaps (considering the feasibility and impact on business)
💡 Build out "The Application Architecture Roadmap" --> An implementation plan guiding the transition.
💡 Stakeholder Involvement :- Yes, this is absolutely necessary --> Need to involve relevant stakeholders as necessary, seek their buy-in, secure their appoval, and ensure their concerns have been addressed. 👍
💡 Governance + Management:-
1 --> We need to define plus implement policies around governance --> Ensuring application quality, consistency and security.
2 --> Plus, establish some best practices around application development, deployment and maintenance (Needless to say)
--> Phase D - Technology Architecture:-
Key intent here is having a "robust infrastructure" to support all of our processes --> the servers, networking & hardware should be able to "sustain" our architectures
I wouldn't be detailing out the process again. This phase too shares similarity in terms of the processes with the previous EA phases.
However, capturing the sequence in brief:-
➡️ Starting out, we'd be assessing the current infrastructure, hardware and networking components (Our Baseline). Then, creating some infarstructure models, network diagrams (the desired state of the architecture). Analysing the differences, and prioritising the gaps. Next, detailing out an action plan for transition, Involving the stakeholders (the one's who're relevant for this phase) , seeking their inputs and ensuring their buy-in (Crucial). Plus, setting up governance and management practices.
-->Phase E - Opportunites and Solutions:-
There might be multiple possible solutions, however we need to identify "the most effective way" to implement target architectures that've been developed in the previous phases.
-->The best bet, given the feasibility, the risks and the benefits they bring to the table
Let's walk through the key activities that make up Phase E:-
Activity 1 --> Identifying potential implementation solutions + checking on its viability
A - We'd start with "evaluating" potential implementation solutions that could help us achieve our target architecture B - Then, "assess the feasibility" of these solutions against technical and financial factors c - Quantify the risks that're associated with each of these implementation solutions, and develop some mitigation strategies
A quick sequence chain to illustrate this:-
Evaluate solutions --> Assess Feasibility- both technical and financial --> Weigh in the risks/ impact and have some mitigation strategies in place 👍
Activity 2 --> Having an Architectural Roadmap in place-->
- Outlining the steps from the current to the target architecture.
- Phasing out, or rather "sequencing" out the implementation projects (--> This makes sure we're having a "logical transition" )
- Identifying inter-dependencies between projects, making sure we're addressing them effectively
Activity 3 --> Every phase ends with a review with the stakeholders, Communicating plans, roadmap with the stakeholders, seeking their formal approval to proceed with the actual implementation. This ensures that our key stakeholders are supportive of the implementation plan, increasing our likelihoods of success 👍
Activity 4 --> Lastly, we'd perform a compliance check, to make sure everything's aligned with the overall architectural principles and standards
In addition to the architectural roadmap, we've also identified the Solution Building Blocks in this phase, that represent the implementations of the architecture's functionality
Moving on to Phase F
-->Phase F - Migration Planning:-
Once, we've developed an Architectural Roadmap, we'll refine & finalise it in this phase:-
We'd create a "detailed" implementation plan , where we'd be going into the specifics:-
1 ---> Resource allocation -- How would you be apportioning resources amongst projects (technology, personnel, budget etc)
2 --> Creating timelines -- Specifics into start / end-dates of projects, Key milestones within projects
3 --> Having some detailed risk assessments and mitigation strategies in place for each of pur projects.
4 --> Consolidate smaller projects into larger ones --> Such that we're streamlining execution by consolidating fragments
5 --> We'd be developing something called "transition architectures". --> intreim architectures during our progression from current state to the desired architectural state.
6 --> A formal approval from the Stakeholders on the plan, and we're good to go! 👍
You might be wondering how an architecture roadmap is different from a implementation plan... Architecture roadmap give us a "high-level, strategic" overview of the initiatives that would be needed to reach our end goal - the target architecture. This means we aren't going deep into the specifics here, howvere, we'd be outling the key projects, highlighting/ sorting out dependencies if any, marking key milestones --> giving them a generic timeline. This is intended for Senior Management or for stakeholders, to get a strategic path and align them with business goals
On the other hand, an implementation plan, is a detailed out, "actionable" plan for executing projects that've been outlined in the roadmap, we're getting into the nitty-gritties of the execution aspects --> Specific projects, their tasks/ activities with their corresponding start and end dates. Plus, would be detailing out Risk Assessment and mitigation plans for each project. This is intended for immediate project managers, architecture team, folks who're actually responsible for executing this...
-->Phase G :- Implementation Governance:-
As the name suggests, this is more around the oversight of the implementation of the architecture if it conforms with the architectural design + ensures alignment with the business
Just a quick heads-up here:- You're "setting up" Governance Structures, or establishing architectural principles, forming commitees/ boards for overseeing governance, in the Preliminary phase, This is crucial. --> Ensuring these frameworks are "applied", "implemented" enforced" during the architectural implementation, is a part of Phase G.
1 --> We'd be utilising governance structures, that've been established in the preliminary phase, to oversee implementations.
2 --> Continuously monitoring projects, ensuring that they adhere to standards and the architectural principles that've been laid down --> Compliance checks
3 --> QA processes to make sure the deliverables meet quality standards
4 --> Managing change to the design. Control and approve deviations.
5 --> Also, documenting the governance process --> Making a note of the lessons learnt + the decisions made + the changes approved
There would be an element of Risk Management and Stakeholder Management in every phase.
However, the scope and the focus area differs.
For instance, in the initial phases of the ADM, stakeholder management would mostly be around seeking buy-in, in the middle ones, it could be around presenting potential solutions, and maybe get an approval for moving ahead with the final implementation plan, while in the later stages, it would be about communicating progress updates, making sure they understand the timelines or support requirements (if need be) & making sure their concerns have been catered to.
--> Phase H - Change Management:-
I had mentioned that managing change is a part of Phase G. Yet, we've got a separate phase dedicated to change management. Why is this so? This is because each phase has a distinct focus
Phase G is about assessing changes wrt the current implementation (That "emerge" during the implementation phase).
These are evaluated, their subsequent impact is weighed upon. The architecture board would ensure that these deviations aligns overall. And a governance process is followed to approve these formally...
While in Phase H, we'd be identifying changes that would need to be made to the architecture on the basis of some "triggers" --> maybe a business strategy shift, some technological advancement or could be some regulatory changes too. But the word "Post-Implementation" is really important here. making sure that my architecture "stays relevant" over time.
How does Phase H look like?
We'd start off with identifying / classifying the changes --> Plus, we'd be evaluating the "impact" of these proposed changes on existing systems, components or stakeholders (the entire Architecture) --> Evaluate the risks it'll bring in, have some mitigation actions in place
We do not want to disrupt business operations. And hence, this phase includes monitoring the implementation
There needs to be a post-implementation review to evaluate the effectiveness of these changes that we've implemented and get them documented
--> The ongoing phase :-The requirements management phase
How does this look like? Here's a quick chain to understand the workflow
We'd first start with collecting / gathering the requirements
↓
Develop a requirements baseline - This'll serve as a reference point
↓
Ensure they've been agreed upon by the stakeholders
↓
Now that you've got the reference point, prioritize them (We'd be addressing the higher ones first to maximise value delivered)
↓
There might be changes springing up (We must have a change management process in place)
- Evaluate the impact
- Review
- Get them approved
↓
Make sure the requirements are traceable (This basically means making sure they're tied to some architectural deliverables, design decisions or some outcomes)
↓
Validate the requirements (Should be Complete, clear, and achievable)
↓
Monitor and Send out updates on their progress