Are we throwing out the baby with the bath water whith agile? It sounds like we are when reading agile topics online and attending agile seminars. Nobody talks about discipled practices i.e. CMMI, TOGAF, IAA, ACORD etc. I get the feeling that maybe it is unknown to those who advocate agile this way? What am I talking about? I believe a more sustainable approach is where enterprise architecture principles underpinned by robust repository based tools like ARIS and agile principles are joined to ensure a sustainable system development process.
The reality that we have in big corporates is that you have a portfolio of programs and projects with multiple stakeholders geographically distributed with various needs and requirements. How do you collate and ensure an integrated enterprise architecture solution with the above in mind? Gartner is very clear on this and says “This is where good EA and portfolio management tools become critical. Doing this kind of portfolio analysis once is possible in Excel. Doing it repeatedly in many different areas is not supportable by a simple spreadsheet tool. So, use tools designed for this problem.” See Meta model below of possible impacts requirements have across programs and projects (by no means complete)
Yes the agilists talk about being lean, little or no documentation, using wiki’s etc. I support this, but the reality is that your project lives in an eco system and this is where wiki’s can play a role, but it is by no means a repository that will allow one to conduct what if analysis based on the above Meta model i.e.
- Are there any other projects that impact the same business service?
- If yes, are they using the same business process?
- If yes, are they using the same activities on the process?
- If yes, then plan on how to collaborate in order to define requirements across projects in order to avoid silo solutions.
Another example would be, the agile team want’s to change an existing application service because of requirements. What will be impacted by this across the enterprise solution? I can go on with countless examples, the point is that your development effort is not isolted, but has to be deployed in an eco system!
So how can ARIS assist one in achieving both goals, being agile yet maintain an enterprise architecture view that is trusted? The solution lies in integrating your SDLC method with your enterprise architecture thinking and if documentation is required, it should be generated from the trusted ESA repository. Documentation sould be a byproduct of the content in your ESA repository. In most cases different roles can access the model content directly from the published content or directly from ARIS in order to approve requirements and to develop solutions. See illustration below of key deliverables with modeled artifacts that support the system development lifecycle. Yes all of the modelled content can be generated to a formal specification if required and is supported by the iBAS solution?
|
SDLC phase |
Deliverable (collection of models) |
Rationale |
|
Concept phase |
Short MS word documemt |
Short MS word documemt stating why the project is required and what the scope is of the project – this is drafted by the product owner or representative |
|
Scope phase |
HBRS – high level business requirement specification |
Identifies the key capabilities impacted from your business architecture (processes) and associates initial requirements to process activities. From this the initial use cases are identified and use case points used to estimate the project effort. The HBRS sets the foundation for the Define / design phases. The HBRS is 100% modelled in ARIS and esures your enterprise architecture is maintained. Generally Concept & Scope should be < than 10% of the overall effort. |
|
Define / Design phase |
Story Card Specification |
Here the agile team decides on what tasks (modeling tasks) are required to realize a user story and then models the content and assesses the impact within the project as well as across projects. This is possible because of all the content residing within the ARIS repository. |
|
Build phase |
Working code |
Story Card Specification used as input |
In summary, the above approach ensures that you create and maintain an enterprise architecture view (logical & physical) and is underpinned by sound notations i.e. ArchiMate, BPMN and UML. So what about amending the agile minifesto to:
Individuals and interactions over processes and tools [supported by lean processes and collaborating tools i.e. ARIS connect]
Working software over comprehensive documentation [underpinned by a trusted enterprise architecture]
Customer collaboration over contract negotiation
