- The organisation will have better planning
- The big picture will be addressed
- The correct people will be informed
- Technology choices will be limited through acceptable standards and frameworks
- Complex designs will be broken into manageable pieces
- Interactions and functions of technologies and components will be understood
What is governance?
Let’s start with a definition of governance. Webster dictionary describes it as “the continuous exercise of authority over and the performance of functions for a political unit”.Gartner has a more specific definition of governance for IT as an “assignment of decision rights and the accountability framework to encourage desirable behaviour in the use of IT”.
In relation to architecture, governance is the charter and rules under which an architectural program operates and the processes that ensure compliance with these rules.
Governance is evident in public traded companies through the Board of Directors who choose the CEO, establish some core committees and set up the high level rules and processes that need to be followed by senior management. The Board of Directors is protecting the interest of the shareholders of the organisation. Likewise the architecture group sets up core committees and high level rules and processes to protect the interest of the CIO and senior management when it comes to setting technology direction. IT Architects are the extension of the CIO and senior management by providing oversight when it comes to making technology decisions and accountability by to making sure this is done efficiently, in line with company strategy and with maximum cost savings.
Therefore, IT architectural governance is part of the overall enterprise governance model that includes corporate governance, IT governance and project governance. Depending on the size of the organisation the IT governance may be limited to an individual like a CTO or CIO or include global, regional and local levels in a large enterprise.
There are many approaches to creating a governance model. The key premise is that governance needs to establish the people via roles involved in the decision making, accountability and the process by which the decision is made. Every organisation has a different culture and style when it comes to establishing governance, but some of the things that are common among organisations are:
- Standards
Standards help speed the decision making process when creating a design, help keep cost down by keeping the number of technologies in an organisation to a minimum and maximise the reuse of technologies. There are a few techniques that can be employed when dealing with standards documents. You can keep an all inclusive standards document and a technology, component or library that must be followed or keep a minimum list of standards that everyone will have to follow and allow individual choice on areas not defined in the standards (for example allow developers or artist to choose their own tools). You also need to define a process for creating or retiring standards and funneling changes to the IT architecture through proper review to minimise the introduction of new and competing standards. You can also break out the standards into regional and global views if it makes since in your company. It is a key element to get senior management to buy in for the standards so make sure it fits with the organisation’s culture if you are going to get people to follow them. The idea is to help make things more orderly and smooth with this document. You want to minimise conflict and make the value of the document evident. I generally include categories on standards documents like: Future, Current, Contained and a date to indicate when something should be retired or into operation as a standard. - Architectural Compliance
How can an architect be effective? People will not necessarily follow the rules if there is no means to ensure compliance and you don’t have senior management buy in and the technologists buy in. This means that you need to sell your processes to senior management and work with the technologists to ensure they make sense to them. This combination will lead to the greatest success. - Architectural Reviews
Architecture reviews is where an architect or group of architects take a look at the proposed designs and make sure it meets the requirements of the project. This is analogous to the concept of code reviews and should be included in the SDLC. This can be a formal meeting on a set schedule and agenda or more informal depending on the organisation. - Architectural Backlog
Agile methodologies have the concept of the backlog which contains the list of outstanding tasks that need to be done. There are always compromises made when designing new systems or inheriting existing technology. Changes that would make the organisation more efficient need to be captured somewhere and prioritised by the architectural group and senior management. Transparency is key to selling needed changes and getting resources to work on them. I feel this is better than padding development time on different projects to work on these things. I like to keep a list of this work and establish a priority to the work. I then like to make this as transparent to senior management about what needs to be accomplished to make the systems better and what would help them meet their goals more efficiently. For example, their goal may be to speed up development. Reorganising the source control tree and breaking out the existing system into components and services may be on the list. This will make it easier to add capacity through outsourcing and make developers more efficient because they will have less effort in merging changes. This aids in documenting the value of architecture. - Architecture Artifacts
There are many artifacts that can be useful to an architect. You can choose a methodology that defines a rigorous use of UML and create many types of specific plans so that everyone will know what is needed or you can ignore and just provide “box and pipes” diagrams at various levels that will show things like component interactions, deployment locations or infrastructure components. You need to decide what works in your organisation and with your SDLC. If there is risk that needs to be mitigated because you are working on projects where mistakes can mean vast amounts of money are lost or you are outsourcing with a formal contractual arrangement, you may prefer to be more rigorous in your design artifacts. On the other hand, many projects benefit from the simpler approach which tends to mesh better with agile methodologies. There are many other artifacts that can be useful, but that is a topic for later discussion. The key point to remember is that artifacts are used for communicating the design of the systems to the project members. Not all projects are created equal and therefore will not require the same artifacts. It is generally good to establish a set of templates or types of artifacts you use in the organisation and define what they communicate to the teams.
Mitch Ruebush is the Leader of the Architecture Team for ING DIRECT, the largest direct bank in the USA. He is president of the Philadelphia chapter of the International Association of Software Architects, and serves on the IASA Board of Directors. He has authored many books and articles and speaks at a number of events each year.
Comments