- In the last video, we briefly mentioned Architecture Compliance. Now you might think that Architecture Compliance just means complying with the Enterprise Architecture. Well, it's a tad more than that. Put simply, Architecture Compliance refers to the extent that an implementation of a system has followed the Architecture Specification. The task of the architect is to make sure there is little or no deviation or variance between the two. The TOGAF Framework identifies six possible compliance states that can exist. This is shown in a diagram which makes use of set theory and Venn diagrams. This might trigger some memories of your math classes. To understand this, it's best to look at these dates in the following order. Fully Conformant is where the implementation exactly matches the specification. Conformant also means an exact match. But with additional paths to the implementation, not in the specification. This situation can occur when purchasing commercial, off-the-shelf products that gives you everything you want and more as part of the package. Compliant is a state of Partial Implementation. Consistent is a mixed up state. The center of the intersecting circles indicates that some part of the implementation has followed the specification, though some parts have not. And the implementation includes things never specified. Irrelevant is a state that can cause some difficulty for the architect, it means the implementation is completely different to the specification and there were no checks done during implementation. It goes without saying that if Compliance Reviews are conducted properly, then this state should never occur. Non-conformant is an interesting state. The Venn diagram shares the same structure as the Consistent but with a small rectangle appearing right in the middle of the intersection. This is an important state because it implies that something has been implemented which meets the specification, but in a way that was not in the specification. So what does this mean? Here's an example, suppose the specification requires that the database to be used is an Oracle Database, but the implementers used an SQL Server instead. This latter option could deliver all of the specified functionality, but from a different vendor. Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of Architecture Governance. The architect function will prepare a Project Architecture in the normal way through Phases A to F. The IT governance function will require that a formal Compliance Review process take place. This is where Phase G, Implementation Governance comes in. Regarding compliance reviews, these are necessary to: one, catch errors in the project architecture early and thereby reduce the cost and risk of changes required later in the life cycle. Two, shorten the overall project time and ensure businesses get the bottom line benefits of the architecture development faster. Three, ensure the application of best practices to architecture work. Four, provide an overview of the compliance of an architecture to mandate it enterprise standards. Five, identify where the standards themselves may require modification. Six, identify services that are currently application specific but might be provided as part of the Enterprise Infrastructure. Seven, document strategies for collaboration, resource sharing, and other synergies across multiple architecture teams. Eight, take advantage of advances in technology. Nine, communicate to management the status of technical readiness of the project. 10, identify key criteria for procurement activities, for example, for inclusion in commercial off-the-shelf products and 11, identify and communicate significant architectural gaps to product and service providers. It's quite a long list, but it's simply reinforces the importance of Compliance Reviews. The Compliance Review Process is pretty straight forward. It begins at Architecture Board level where the decision to perform a review is made. You can see this process in the top track. The people or organizations that will be the subject of the review are identified and an architect appointed as coordinator. Then there's a consideration of what needs to be included in the review. Once the reviews had been scheduled, we moved to the bottom track. It's then a case of reviewing the implementation with the specification, using the checklist and documenting the outcome. The report is returned to the board, copied into the subject of the review. The board will then sign off if appropriate. Finally, let's consider how you might go about establishing an Architecture Capability in the context of Architecture Governance. The best way to do this is to treat Architecture Capability as a candidate for an ADM Project. In relation to the following areas of the ADM, Phase B, Business Architecture. will highlight the architecture governance, architecture processes, architecture organizational structure, architecture information requirements, architecture products, and more in relation to the Architecture Capability. As Phase C, Information Systems is a composite phase. It will cover both Data and Application Architecture. In the case of Data Architecture, it'll define the structure of the organization's Enterprise Continuum and Architecture Repository. Application Architecture, on the other hand, will specify the functionality and application services required to enable the architecture practice. And Phase D, Technology Architecture depicts the architecture practices infrastructure requirements and deployment in support of the Architecture Applications and Enterprise Continuum. That's the end of this video on Architecture Governance. The final video in this module, will look at the views and viewpoints of stakeholders within the enterprise.