More often than one would like to, I get to read online and come
across misguided grievances from seasoned IT leaders (and surprisingly
enough NOT so much from the business side of the house),
on online private/public forums and otherwise also that EA is good only for
organizations that have established businesses and lots of money to spend on
IT. Some of the most commonly used phrases that I have come across in last
3-4years -
"EA and Business Agility are oxymoron"
"Enterprise Architecture is rigid and inflexible"
"Enterprise Architecture makes the SDLC process heavy and dense"
"Enterprise Architecture works only for the companies that run on waterfall SDLC model"
However, contrary to the fairly common misguided beliefs EA is
actually critical for progressive businesses and is often deep rooted in
organizations with rather frugal IS&T. If anything, EA makes SDLC more efficient and agile - when applied correctly.
Without getting into religious debate about whether EA should report into CEO or CIO, I would like to focus on a simple objective of having/building an EA practice. In layman terms - Enterprise Architecture is the formal practice/group/team to align the business strategy with the IT spending, and Enterprise Architects achieve this goal by collaborating and working closely with number of stakeholders across the board on business, application, PMO and QA side of the house. In my experience I have partnered with PMO and Portfolio managers to help lay down an iterative SDLC model, with a foundation build upon Agile principles.
Zachman, TOGAF, FEA, Oracle EA (thinly based on TOGAF), and
Gartner Meta Model frameworks are possibly the most famous EA frameworks in the
market right now. However, for the purposes of indicating the alignment between EA and agile SDLC, this blog series focuses only on TOGAF and Zachman models.
Aligning Zachman with Scrum
Zachman framework is probably the first formal EA model that
provided users with a robust framework that could be custom-built to fit
various LOBs and domains. The Zachman "Framework" is actually taxonomy
for organizing architectural artifacts that take into account both - who the
artifact targets and what particular issue is being addressed. Though Zachman
model was originally envisioned for a SCM, but over a period of last 40+ years
since it's existence it has been used in innumerable scenarios and LOBs outside
the SCM industry, which is a testament of the robustness and universality of
the EA frameworks.
In simple terms Zachman is a 6x6 matrix with taxonomy from 4 different consumers views - Enterprise Names, Model, Audience, Artifact Classification. For the purposes of showcasing alignment of Zachman with Agile, I would focus completely on the Enterprise names and Classification names and I would try and mould the original model in a newer model that aligns easily with the Agile principles.
In order to align and rhyme with the Agile theme, I have re-ordered the classification names (Zachman does NOT tie the user to itself rigidly) in the revised model.
In the revised Zachman picture below, the original Enterprise names have been revised in an attempt to help align the model closely with geographically and physically spread modern enterprises.
From here, we could dwell a level deeper and see how the revised Zachman could be plugged into the scrum SDLC for defining each user story. The section highlighted in Yellow above is representing a scrum user story at operational level, capturing the details in a pre-defined template/format. When this revised Zachman model is plugged into the Agile [REF-2] SDLC, organization could benefit immediately/earliest in shape of -
On the flip side - Agile being an umbrella for multiple known methodologies, i.e. Scrum, Kanban, Scrumban etc, I believe it could be moulded to meet the organization requirements and just like we saw how Zachman framework could be custom-built to suit to the organizational expectations and culture.
In order to align and rhyme with the Agile theme, I have re-ordered the classification names (Zachman does NOT tie the user to itself rigidly) in the revised model.
In the revised Zachman picture below, the original Enterprise names have been revised in an attempt to help align the model closely with geographically and physically spread modern enterprises.
- 'Event' here indicates the trigger or alarm condition for the the business flow or process to begin.
- 'Capability' reflects upon the business rules and principles encompassing the asset or action to be taken
- 'Function' could be auto or manual or a combination to define course of action.
- 'Asset' could be an object, piece of information, ER et al. It could be anything that business considers as an asset.
- 'Location' could be on cloud or on-premise or hybrid, location of the asset on which the action is to be taken.
- 'Reason' should be included for tracking purposes so that we could establish why a change was made or suggested.
From here, we could dwell a level deeper and see how the revised Zachman could be plugged into the scrum SDLC for defining each user story. The section highlighted in Yellow above is representing a scrum user story at operational level, capturing the details in a pre-defined template/format. When this revised Zachman model is plugged into the Agile [REF-2] SDLC, organization could benefit immediately/earliest in shape of -
- primarily, every user story would not have a story/theme
- it would be able to provide consistency in capturing requirements in the right details for all the projects,
- it would also be able to provide just the right amounts of details at the front end of the process,
- it would enable the solution and technical engineers to work in close collaboration with the business analysts during the conceptualization phase,
- this approach might also help in reducing the backlogs between sprints.
- finally, this is extensible solution and can easily be modified to align with any change(s) in business and/or EA guidelines.
On the flip side - Agile being an umbrella for multiple known methodologies, i.e. Scrum, Kanban, Scrumban etc, I believe it could be moulded to meet the organization requirements and just like we saw how Zachman framework could be custom-built to suit to the organizational expectations and culture.
