Effective enterprise architecture programmes create and enforce company "technology standards" that guide the selection of hardware and software throughout the organisation. These standards define the technologies and products that best fit the guidance generated by the enterprise technical architecture (ETA) process.
Creating these standards, though a painstaking and methodical process, is the easier part of the job. The critical challenge is to enforce compliance with standards in both investment decision-making and the context of project efforts. Without successful enforcement of technology standards, the value of enterprise architecture is limited, and the architecture programme will be more of a platonic intellectual exercise instead of actively steering the organisation`s technology strategy.
IT organisations employing ETA establish company technology standards using information technology requirements (ITRs) determined by the business/technology common requirements vision, general and domain-specific architectural design principles, and the organisation`s position on industry standards to categorise the lifecycle of existing technologies in the portfolio. This same approach can be used to assist in the determination of proposed new technologies to be added to the environment.
Design principles from technical domains (eg, application development, platforms, security, network) provide guidance on what is important in the selection, creation and implementation of specific technologies. ITRs describe the general attributes of the technical environment that a specific technology or product must enable (eg, supports real-time exchange of data, access from mobile users, or a consolidated store of customer information). The organisation`s position on technology standards further constrains choices (eg, supports specific IEEE specifications, supports regulatory requirements) for both current and new technologies. Positive matches of products and technologies to this guidance receive a green light, those that are non-compliant receive a red light, and those that are "on the fence" receive a yellow light. Each organisation must create a weighting of these "lights" to determine if a product meets the guidance for a company standard.
By combining domain-specific design principles, ITRs, and the position on industry standards with a full spectrum of considerations for a marketplace (eg, market presence, market performance), an organisation can clearly discern the leaders and followers that meet (or fail to meet) its requirements to qualify as a standard. Conceptual architecture principles from enterprise architecture help constrain viable products and vendors by describing, for example, the leadership threshold stipulated (eg, "We will select only mature technologies," or "Technology leaders, not bleeders"). Resulting ETA technology standards and design principles drive market performance considerations. With appropriate weighting to define the relationship between presence and performance, the company can quickly spot the technologies and products in a specific market that fit with its future-state direction as described in its ETA.
If guidelines derived from the ETA process are not instilled in the organisation`s technology sourcing processes, purchasing decisions will continue to be dominated by individual project leaders or business units making choices based on parochial concerns as well as limited awareness of the company`s overall business and technology strategy.
Typically, input from the ETA into technology purchasing decisions will be exerted in three phases:
1) As a set of explicit guidelines for various technology alternatives in different domains, categorising each according to its level of compliance, permissibility, or applicability (eg, green/yellow/red, preferred/transitional/obsolete, enterprise/department/R&D);
2) In a consultative model, where project teams work directly with architects to define and categorise technology alternatives; and
3) In a final review process, whereby the enterprise architecture programme approves or denies each significant new technology decision.
Effective internal communications will minimise the extent to which the governance exercised by enterprise architects over purchasing decisions will be seen as a negative constraint by project sponsors. After all, this guidance will remove doubt, shorten design phases and decision times, eliminate risk and provide the broadest possible perspective of the choices available and their consequences. Even if, in the short-term, a non-compliant technology might seem to be a better solution for a specific project, in the long-term, that project`s chances for success will be bolstered by fitting into the evolving enterprise business and technology strategy.
Of course, instances will occur when project leaders or senior executives are determined to defy the ETA guidelines to select a technology with a low price, fast implementation time, or specific functionality that does not fit with the long-term road map. This also applies to already installed technologies with sponsors that wish it to be perpetuated even though it does not fit with the long-term direction. In these instances, the role of the architecture team is not to absolutely require compliance with its recommendations. Rather, it is to ask tough questions of project owners (via an explicit exception-handling process) to determine the benefits that balance the negative consequences of the non-compliant technology (eg, increased risk or complexity).
Enterprise architects and project teams should exploit this governance and exception-handling process as a feedback mechanism to infuse additional information on domain-specific design criteria into the enterprise technical architecture. Especially for newer enterprise architecture programmes, there will be many domains where the project team finds that the architectural road map does not yet contain complete information for a specific technology domain. The project team should then work with the architecture team to establish appropriate selection criteria, which can be leveraged by future projects.
USER ACTION: Enterprise architecture programmes should include appropriate governance to help organisations make quick decisions while imposing the organisation`s technical standards architecture on buying-level discussions. The effect should be to empower the enterprise perspective over project-focused technology purchasing decisions.
"Most organisations are still making decisions on a project level," says META Group analyst Philip Allega. "But CIOs must not allow project teams to make parochial choices of products without considering the future state. Otherwise, the ability to leverage value of those investments for the long-term is inhibited."
To achieve this goal, IT organisations need to make explicit the relationship between purchasing evaluation and decision models (eg, METAspectrum) and higher-order design principles and future-state guidance that dictate why they should weight specific criteria at certain levels. The enterprise architecture programme should also measure and track the level of compliance of purchasing decisions with the technical architecture road map as a key parameter for gauging the effectiveness of the EA programme.
META Group analysts Richard Buchanan, Philip Allega, Audrey Mickahail and David Yockelson contributed to this discussion.
Share
