From the Blogosphere
Agile Governance | @DevOpsSummit #Agile #DevOps #APM #Microservices
In many organizations governance is still practiced by phase or stage gate peer review
By: David Sprott
Nov. 9, 2016 02:15 AM
“Last year the decision was finally made to mandate Agile across our enterprise. The decision was taken, even though there were many unanswered questions. The assumption was that forcing the migration, along with adoption of popular “enterprise Agile methods” would ensure resolution of the outstanding questions. In practice, Agile methods have been very effective in delivering specific digital business initiatives. But almost inevitably the distribution and delegation of architecture has resulted in duplication, inconsistency and increased complexity, across all project types including legacy and new projects. We are now concerned that we no longer have an effective governance capability. The question is how do we fix this without losing the undoubted benefits of Agile methods?“ Enterprise Architect, F2000 company.
d) A Community of Interest (CoI) responsible for the governance system and communications
Agile Governance Model
This is a much simplified Agile governance model. Key points to note are:
1. the centricity of the architecture runway, and the tight relationships between policy, reference architecture, reusable assets and the automation platform.
2. variants guided by various dimensions of scope, which may include applicability, business or technology domain, or even the maturity of the business or technology domain to achieve compliance.
Principles are a great place to start. Self-governance is going to be a key part of Agile governance, and if we can’t articulate and communicate what’s important then we are dead in the water. Some examples shown here:
Reference Architecture is a critical capability, defining the architecture styles and patterns and applicability. But reference architecture shouldn’t stop at models, it must be realized in code in the Design Platform – which progressively realizes the reference architecture as application level infrastructure reusable across multiple projects. The design platform is typically managed by the CoI, a collaboration of senior developers and architects that decide what should be in the platform and develop the models and code as exemplars that succeeding projects will be happy to use, customize and or extend. The design platform is therefore a critical governance tool that actively evolves, managed by the CoI and constantly challenged by project developers to provide optimal solutions to delivering on the principles and reference architecture. As a by-product the mature design platform will also be a major productivity tool; for example in the Everware-CBDI Agile Service Factory, over 80% of the code for typical large projects will be automatically inherited from the platform.
As shown Principles are generic patterns or techniques that guide strong solutions to business problems. The application of Principles is achieved by Policies. But not your father’s policies! In many (most?) organizations Policies are outdated lists of standards. In Agile governance, policies should be a context based record of how the principles and reference architecture have been realized. Like principles, policies are not mandates from senior management, they are transparent communications of pragmatic decisions made by the CoI on the best way of delivering an optimal result in a particular context, reusing tried and tested methods supported by existing architecture and design assets. This is therefore a continuously evolving body of knowledge, specifically tailored for one enterprise’s needs. Examples below. Note in particular the Policy Context that highlights applicability and exemption.
Many Agile teams are now using the Scrum of Scrums approach to coordination of multiple projects. This is a highly effective mechanism to manage the pan-Scrum backlog. However this coordination must not be confused with architecture realization. The Community of Interest is not a Scrum of Scrums, it is a group of the most respected architects and developers who will be active practitioners in architecture and development projects, who coordinate the realization of the architecture, the models and implementing code, typically in direct response to project demand, but involving CoI members as appropriate to review, refine and contribute to improve the solution, to be optimal, generic, principle and policy compliant. The Architecture Scrum may therefore on occasions be a series of architecture specific sprints, perhaps at commencement of new programs, or in response to significant new areas of reference architecture or design platform requirement. But in momentum situations the Architecture Scrum is more likely to be integral to multiple development Scrums.
In a generic sense, governance is concerned with ensuring the integrity of the delivered product. This requires a strong focus on the architecture and how it is realized. As many organizations are now realizing, delegation of architecture in an uncontrolled manner is high risk. The approach outlined actually encourages delegation of architecture but to a coordinating body, the CoI, which itself is charged with supporting project demands and broader organizational objectives. But the approach outlined also recognizes that there needs to be explicit documentation of architecture principles and policies and their application in order to allow communication and review, and justification of business value. This is a necessary level of documentation needed to communicate to the many stakeholders involved.
Reliance on opinions expressed on a case by case basis, or architect resource involvement in projects without the backing of strong, defined reference architecture, gives programs or projects far too much discretion. Whilst we may laugh at John Cleese’s magic dust, in practice the embedding of key architectural code into the platform layer actually does make governance considerably more effective. But even if it’s incredibly effective, it’s not magic. An effective CoI comprising the very best architect and developer skills available means all projects have access to optimal solutions as well as automatic compliance. Agile governance as described in this post is therefore not an extension of Agile methods per se, rather it is a bridge between Agile methods and agile architecture that defines and ensures desired outcomes, without compromising the integrity of the Agile process.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week