Putting the Architecture Process to Work - IT Planning and Procurement

---

Putting the Architecture Process to Work — IT Planning and Procurement

Clearly, an architecture process requires a significant investment of time and effort. Given the up-front and ongoing cost of the work described here, how does one ensure the greatest benefit to the organization? One of the best vehicles for sharing and leveraging the accumulated knowledge of the architecture process is the enterprise's intranet. Through an architecture Web site, the architecture team can organize and present process findings attractively and economically. Each domain team can publish its updates to the site, keeping the knowledge base current. Most importantly, through the effective use of hypertext, document tagging, and end-user navigation design, the site's technology grid and other means of access can link numerous internal and external information sources, leaving the depth of data mining to the user. See Exhibit 7.

Exhibit 7: The NEF/IS Architecture Site Home Page

As depicted here, the NEF/IS architecture site home page readily conveys the domain structure of the process and affords easy access to domain-specific knowledge. This particular site also serves to inform and promote new IT standards, products, and services to the rest of the NEF/IS team. Throughout, the tone is positive and tailored to its technology audience. This Web approach also simplifies data collection and distribution. There is no need to create vast amounts of paper documentation or to limit oneself to any particular presentation medium. Furthermore, because many architectural elements will be supplemented with content from external, third-party providers, a Web approach affords easy integration among Web sites for added technical and product information.

Thus, much of the detailed data collection may be left to others. Just create the links from the enterprise's intranet across the firewall to external Internet sites. As new technologies emerge and as the enterprise invests in different IT products, these changes may be readily reflected on the intranet site through domain team self-publishing (i.e., adding to the technology grid and the library of product information pages and links). The result is a single, highly accessible, and current source for all architecture-related information.

Beyond serving as a data repository and one-stop reference library, an architecture Web site may also afford a venue for cross-functional collaboration. Through domain-based discussion forums, those technologists who do not formally serve on domain teams have an opportunity to comment and expand on architecture contents. In so doing, they may also influence the outcome of enterprise technology selection. See Exhibit 8.

Exhibit 8: The NEF/IS Architecture Process Forums Structure

By employing a series of subscription-based discussion groups, interested parties will receive e-mail notices of any discussion forum updates. Through these forums, the greater NEF/IS community got involved in the architecture process, enhancing content, offering insights, and more generally buying into the knowledge sharing and standards compliance efforts. By ensuring the overall quality and comprehensiveness of the site, process participants draw in operational users looking for background information on existing systems, development tool options, and strategic technology directions. For most of the NEF/IS organization, this was the first time that they had enjoyed access to such extensive, current information. Indeed, one of the most immediate and heavily used aspects of the Web site was the product sheets that identified particular IT product and service owners/experts.

If the first measure of an architecture process's impact is the extent to which it becomes commonly used within the IT organization, the advent of a well defined and easily navigated NEF/IS site succeeded in engaging our systems developers and technology integrators. They began to employ it as a reference tool. Over time, this use translated into less time wasted searching for technical information, the leveraging and occasional reuse of technology components, and a greater adherence to IT standards and practices. ^[10] These consequences contributed in turn to lowering the cost of developing and maintaining IT products and services. Although NEF's lines of business still drove the purchase or in-house development of applications, with the architecture site in place, NEF/IS was positioned to advise them on their IT choices in a more effective and timely manner.

Although all this value may be appealing, the communication and use of an IT architecture framework is but one of its major outcomes. Two other aspects of this work should be emphasized, namely its capacity for auditing and for advocacy. In terms of the audit function, it is not enough for the process architect or the PMO to support passively the distribution of information to the IT community. These process staffers must continually monitor adherence to the standards articulated in the architecture. To this end, the author recommends a two-tier approach to auditing. On the one hand, the process architect should meet regularly with operations and systems development teams to ensure that there is an understanding of and general agreement with the organization's IT architecture framework. On the other hand, the architect should hold formal quarterly reviews of the enterprise's architectural compliance and communicate audit findings to IT organization management. See Exhibit 9.

Exhibit 9: An IT Architecture Audit Summary View

Here again, the Web site may facilitate information gathering and sharing, as well as encourage compliance. The tool as employed at NEF/IS captures the following items:

• Status of the domain team's operating principles and frameworks

• Completeness of the domain's information grid, referred to in the example as the technology matrix

• Completeness of the individual product and service information sheets that flesh out the information grid

• Status of the team as an ongoing operating unit

Each domain team report indicates the work completed to date (white), work under way but not yet complete (yellow), and work that is stalled (red). In the spirit of continuous improvement, the support team helps its domain team colleagues identify those areas where either the architecture itself is lacking or where there is a need for greater effort by the domain team in defining and establishing IT standards. Here, you may wish to involve your IT organization's executive leadership more directly in setting a direction and ensuring sufficient time and focus for the process in support of your domain teams.

By monitoring compliance, the architect or the PMO educates the greater IT team about the gaps in IT architecture standards and knowledge while continuing to expand on and improve that foundation for informed action. Of course, not all the news that comes out of architecture audits will be well received, especially by those cast in a poor light. Auditors are never the favorites of those who fail to live up to their obligations. If the rules of the game are set out clearly in advance, however, and if all agree to play by those rules, the outcomes of audits should merely confirm what is already known. Furthermore, the findings of these audits may encourage additional attention to and perhaps resources for those areas of the architecture discovery process that have fallen behind schedule or that cannot keep up with the growing body of knowledge pertaining to their area of focus. In general, the audits at NEF/IS were received in this manner and contributed to the long-term strengthening of the overall process.

Lastly and perhaps most importantly, the architecture process affords a platform for the advocacy of best practices, for the disciplined life-cycle management of products, and for the introduction of new technologies. The architecture framework is a compendium of best-in-class solutions that marry with the enterprise's business requirements. If a particular solution has demonstrated its worth to the organization, these results should be championed by the architect and the appropriate domain committee. A complementary software engineering process, if applied across IT, will offer yet another venue for the architect and the PMO to advocate for the use of a particular technology across many different settings. Any occurrence along these lines reinforces the value of the organization's ROI on its architecture process investment.

Similarly, once the architecture has established an IT standard, management will possess a metric for assessing technology choices that are ultimately tied to ROI and the expertise of the IT organization. For example, most organizations have a difficult time retiring technologies. With an architecture knowledge platform, as illustrated in this chapter, IT management will be better positioned to establish expiration dates for enterprise hardware and software and to set business rules for the sunsetting of particular system components. This takes some of the political risk out of the effort for those directly involved, by promoting change in line with the overall direction of enterprise IT strategy and the application of accepted standards of measure. In fact, the author can point to several occasions when the parent of NEF, MetLife, employed information drawn from the architecture knowledge store to support system consolidations and other cost-saving measures.

Finally, the tool created by the IT architecture process will position participants to influence the strategic direction of technology investments. Through the applied research stored on the site and the associated forum discussions that these findings will stimulate, the process may be employed to identify specific choices and to build a strong consensus in support of these choices. Nor must these decisions emanate from the top of the IT organization. As the opportunities suggested by IT innovations become apparent to those serving on domain teams, these participants are ideally placed to develop and share ideas in line with the enterprise's business needs and the IT operational requirements. Through Web site forum discussions and associated applied research, refined versions of these bottom-up proposals may then be placed before management for formal consideration and action if appropriate. As the author witnessed at NEF, when proposals for change evolved out of architecture process activities, these plans enjoyed broad backing from NEF/IS technology thought leaders and service delivery managers. For that matter, because they were always framed within the context of document standards and best practices, they also tended to fit well with the rest of NEF's IT infrastructure.

^[10]IT organizations that adhere to a software engineering framework and related disciplines will find that this architecture process nicely complements other process improvement efforts. When best engineering practices are married with sound architectural design standards, there are typically more predictable and higher-quality outcomes to systems development and integration efforts. If this is the case, it makes sense to give the oversight of the architecture Web site to the PMO.

---