“They don’t really know what agile is. All they know is the word.”
– JOHANNA ROTHMAN
You are working in multinational banking and finance company, which is implementing Agile IT development practices on a massive scale, thus having high expectations on improved efficiency and customer value.
The sceptics would say, but how to deal with IT architecture in the agile world, in which each team member is called developer, and where the planning is exchanged into the tolerance of making mistakes?
Putting all the arrogance aside, the issue is to find a really flexible method to deal with architecture, gaining sufficient value, and prove that not only startups and fin-techs can gain by following agile.
You are assigned to lead the architectural work and have a task to describe what content is reasonable to have for simple and clear domain architecture description, which supports quick creation of good solution architecture designs.
Architecture description guidelines
A stakeholder addresses his concerns about the systems by understanding architecture. And architecture can be understood only if it includes the right views for stakeholder and is described using commonly understood description languages.
Picking the right view is an essential task to cover the concerns that different stakeholders have. So what do we choose to represent in simple and clear persistent architecture which is constantly maintained. Here is the exemplary structure of architecture deliverables.
Enterprise view
Cross-domain interaction map
IT service list
Logical view
Systems maps
System context diagrams
Implementation view
Component diagrams
Deployment diagrams
Data view
Logical data model
We start with the views of higher level of abstraction compared to any other used in system design. It‘s not enough to describe the behavior or functional part of a particular system, it‘s equally important to maintain the overview of system in the context. As example, Woods & Rozanski noticed the limitation of standard modelling frameworks, like 4+1 views, and introduced the context view. The context diagram describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts). The view addresses concerns like system scope and responsibilities and identity of external interfaces.
When it comes to reusability of describing architecture in the Agile projects, the above mentioned views could be checked out to modify and prepare the solution documents, and later checked in back to persistent place.
On solution level is often enough to take system design perspective and higher level of abstraction views remains unmodified.
Logical view
System context diagrams
Implementation view
Component diagrams
Deployment diagrams
Data view
Logical data model
EA Value
Enterprise architecture team enforces guidelines and best practices of creating architecture artifacts, which later reused in development lifecycles, like Agile. Having an architecture described and maintained ensures the balance between speed, stability and longer term perspective. At the end, the final customer gains from increased time to market and better customer experience.