In a previous blog I highlighted the need for a SOA Governance Model and that model should include empowered organizational governance structures. I thought I would cover this in more detail.
Traditional governance brings to mind the setting up of management boards or steering committees. I have sat on many of these boards and while these structures have value they are not the only organizational structures required.
SOA has increased the importance of a number of change management requirements. Therefore, any organizational and change management model must cater to the increased levels of collaboration and quicker governance decisions required by architects and projects teams.
Successful SOA initiatives require active leadership and none more so than acquiring some level of executive sponsorship which empowers newly formed or updated structures with not only the mandate but also the appropriate authority.
Successful SOA Governance starts from the top to drive adoption and commitment. The level of active leadership actually drives the design of the SOA Governance model.
A key aspect of SOA Governance is the updates or creation of new governance structures to define/monitor and enforce policies surrounding the enablement of the SOA initiative. The number and names of these structures is less important than the roles and responsibilities they encompass. The names of the structures are arbitrary as an IT steering board, IT committee, and architecture review board could all perform the duties within different enterprises.
SOA Steering Board
Leadership structures such as IT/SOA Steering Boards tend to be staffed with senior management stakeholders who provide the executive sponsorship for the SOA initiative and set the business priorities. It is advantageous to have both business and IT representatives to set and define the vision and strategy as well as establish the appropriate funding models. The SOA Steering Board should also be the final authority for any exception management decisions that need to be made. In many enterprises the roles performed by this structure can be addressed by existing IT steering boards or as extensions of IT steering boards.
SOA Architecture Authority
The SOA Architecture Authority not only enables the strategy execution as defined by the SOA steering board, but also is the custodian over the official SOA Reference Architecture. This structure tends to be staffed by internal experts, but in the early stages can be supplemented by external experienced practitioners. Roles focus around the different aspects of SOA architecture and methodology, from defining approved standards, processes, and products to adjudicating architectural priorities and issues. In many enterprises the roles performed by this structure can be addressed by the enterprise architecture team or an extension of the enterprise architecture team.
SOA Center of Excellence (aka SOA Enablement Team)
A SOA Center of Excellence (COE) allows enterprises to focus more resources and funding on innovation and project delivery while reducing the complexity involved in executing SOA. The SOA COE supports project teams in a variety of ways, from making available experts as a SOA skills and resource base, to enabling overall corporate competency development. While this team should be seen as a project enabler, they do have the charter to assure SOA governance compliance. This team tends to be staffed by experience SOA architects who understand the SOA Reference Architecture, associated standards, best practices, and defined SOA governance policies. In many enterprises the roles performed by this structure can be addressed by extensions to existing structures such as an Integration Competency Center.
Service Advisory Council
It is common for enterprises to define structures that are the custodians of the Service portfolios. Sample duties include maintaining the integrity of the taxonomy and metadata, assisting with Service candidate approval and with the development of a Services blueprint, and monitoring the Service usage/reuse. Example roles include Service registrar, Service portfolio owners, and business domain SMEs.
It is common for enterprises to separate the development of applications from the development of Services as each approach can utilize a different development methodology and eases the option of outsourcing. Each approach requires a different mindset, processes, and organizational structures. There are many different patterns that can be used to address Service engineering structures. I will address the patterns I seen at enterprises over the last couple of years.
Good Luck, Now Go