The Process of Building and Maintaining an IT Architecture

 < Day Day Up > 



An architectural process should be highly collaborative, involving a cross section of IT management and technical experts. To initiate this process, draft a team charter that clearly defines roles, responsibilities, and process deliverables. The elements to be addressed in such a charter may be summarized as follows:

  • Process sponsor — typically, the enterprise's CIO and his or her executive team. Process sponsors must sign off and endorse the process. Without their clout, you may not get buy-in and hence the time and attention you need from rank-and-file IT thought leaders.

  • Process customers — the enterprise's IT team. By its very nature, the IT architecture is highly technical and not meant for the use of the IT organization's customers (i.e., end-users). Rather, it is employed by the IT team proactively to meet the needs of its customers.

  • Process participants — an IT executive leader (as project director), one or more IT architects (as technical and integration experts), [5] members of the PMO (as process facilitators and knowledge managers), and various technology domain teams (as content providers). [6]

  • Process deliverables — the creation of a clearly articulated and comprehensive framework for all the technology currently deployed within the enterprise, indicating what is in place, sunsetting plans, future directions, established and anticipated standards, and so forth. This outcome will be enhanced if it also identifies those persons responsible for the IT systems, services, and products mentioned in the architecture documents, as well as their contact information. Furthermore, it is essential that the process embrace an outcome that sustains the IT architecture process itself over time.

  • Process timetable — two phases. Phase 1 (6–12 months) involves the initial establishment of the architecture; Phase 2 involves ongoing, continuous maintenance of the framework. Your timetable will depend on the urgency of your organization's need for an architecture process and the availability of resources you can devote to this effort. In the case of NEF, process participants worked this project into their already-packed schedules, hence its elongated delivery timeframe.

  • Resources required — a limited amount of dedicated, high-level technical expertise through the assigned IT executive and his or her architect(s); ongoing support from the IT organization's technical teams as part of their business-as-usual task work. [7]

As indicated, the process must come with the full support of the IT organization's management team. Without its good will, the architects will have no access to the attention and expertise of those within IT operating units whose input is necessary for the development of architecture knowledge components. The success of the overall process is contingent upon drawing out knowledge from a significant cross section of the IT organization and in keeping those people involved in the ongoing maintenance of process deliverables. Because the ultimate audience for architecture documents will be the IT organization itself, the process must communicate effectively and economically to this audience. Thus, involving the technology thought leaders within your organization — and keeping them involved — is essential to the overall quality of the end result.

As an organizational principle, most architecture processes are built around various technology domains or areas of specialization. These groupings allow process participants to focus on and build a critical mass of knowledge around those categories of IT products and services that matter to the enterprise. Those who consult in the area of IT architecture planning have strong feelings about the number and description of these domains. The author does not share this concern. In brief, the organization of an enterprise's architecture process must be driven by its own business and technology needs. As long as the structure encompasses all of the technologies in play within the organization, it suffices. For these reasons, within NEF/IS the author employed an IT architecture advisory board to derive an IT domain model for NEF. Through a series of brainstorming exercises, the process team came up with a list of IT architecture domains. The reader's list may differ. The litmus test for its appropriateness is that when you are done, the list must embrace all those technologies that reside within your business. See Exhibit 2.

Exhibit 2: An IT Architecture Process Technology Domain Design

start example
  • Application development — encompassing application development and testing tools, methodologies, templates, frameworks, application technical design, and an application development infrastructure for messaging, component reuse, etc.

  • Business applications — encompassing the total life cycle of the portfolios of manufacturing, distribution, and corporate information systems employed by the enterprise

  • Data — encompassing database design tools and methods, directory technologies, database management systems, and data administration tools and systems.

  • Desktop and collaboration — encompassing desktop, laptop, and personal data assistant (PDA) hardware, operating systems, and productivity software; also e-mail, calendaring, groupware, and related technologies

  • Human factors — encompassing design methodologies, graphical user interface guidelines and standards, usability testing techniques and tools, and Web authoring tools and design standards

  • Knowledge management — encompassing data warehouse and mining, online analytical processing (OLAP) tools and methodologies, and knowledge capture, storage, and access

  • Network infrastructure — encompassing telecommunications and local and wide area networking technologies

  • Security — encompassing IT security technologies

  • Server/mainframe — encompassing departmental and enterprise-level servers, storage systems, printers, scanners, backup systems, etc.

  • Voice — encompassing telephone switches, voice mail, voice response systems, call-center technologies, etc.

  • Web and Internet services — encompassing Web-specific products and services that either stand alone or enable other enterprise IT products and services

end example

Again, this list is merely illustrative, serving as an organizing framework for those laboring within the process. Each domain will have its own team leader, preferably the most senior in-house expert in that particular subject matter, and should include a healthy cross section of domain-specific representatives. In the case of NEF, the author, as the executive responsible for the overall architecture process, served ex officio on each domain working group, as did the IT architect. Together, we acted as process guardians, facilitators, scribes, and timekeepers of domain team deliberations. We also worked as the integrators of domain team activities and the creators of the artifacts and KM systems emerging from their collective efforts. In the reader's case, PMO personnel may serve alongside or in the place of IT architects to keep these efforts on track and to chronicle results. See Exhibit 3.

Exhibit 3: The NEF/IS Architecture Domain Teams

start example

click to expand

end example

Although product and service managers may participate on teams (as they did in the case of NEF), it is recommended that the working groups primarily include those with direct, hands-on experience with the technologies in question, as well as those who have a strong interest in the evolving body of knowledge encompassed by each product or service domain. Some organizations will separate the operational servicing of a technology from related applied research. The domain team should include representatives from both functional areas. At the same time, no domain team should exceed ten members. Otherwise, process overhead will become burden-some, slowing team decision-making. Bear in mind that, in other ways, the architecture process is inclusive. Any number of additional technologists may be solicited for their input without requiring them to serve in a working group. Most importantly, each domain team is an advisory/advocacy body to focus data collection and conversation. The architect (or the PMO) serves as the auditor of enterprise compliance with architectural standards, while the corporation's IT operations managers serve as implementers of the actual technologies once those are chosen.

After the executive NEF/IS leadership reviewed and approved the process charter and the organization and membership of the architecture domain teams, the author and his colleagues received a mandate to proceed. From the outset, I made it clear to those participating that this process should be integrated with their day-to-day work. Our underlying work assumption was that as they used technologies in-house and as they followed developments in their fields of expertise, they would also apply this knowledge to building and documenting an IT architecture framework for NEF. Thus, it was our hope and expectation that the process would merely formalize what these IT specialists had been doing all along. To facilitate these outcomes, the author and his colleagues, who constituted a virtual PMO team, provided process management, simple information-gathering tools, and lots of encouragement.

Freed from the detailed administrative and KM minutiae that naturally accompany an IT architectural process, the domain teams focused on grass-roots information gathering, communication, and data analysis concerning the IT products and services in play within NEF. With the aid of the process tools provided by my office, the teams grew a body of knowledge that addressed the following areas of interest:

  • Domain principles — these include any particular principles and assumptions that shape the architectural decision process for that domain or that delimit the discussion around domain products, options, and standards. This content builds on the charter and assumptions of the overall process but also provides greater definition to the roles and responsibility of the domain team.

  • Domain technology grid — this framework includes all of the domain technologies in place within the enterprise or planned for acquisition, including the following:

    • Technical description of the current state [8]

    • Transition strategies and sunsetting plans

    • Near-term migration targets (two-to-three year timeframe)

    • Underlying standards

  • Supporting documentation — this may come in many forms: vendor publications, consultant or in-house generated research, requests for proposals (RFPs), bibliographies, URLs, etc.

To bring this information together and to give it focus, the support team created a Web site organized so that each technology domain would have its own work space and tool set. This site promoted collaboration and afforded an ideal venue for communicating process results to the greater NEF/IS organization. See Exhibit 4.

Exhibit 4: An IT Architecture Domain Team Home Page

start example

click to expand

end example

The list of process deliverables comprehends all of the critical information required for action. For example, if NEF/IS managers want to know what particular technologies are in place within the firm today, all they need do is drill down on the Web site to uncover this information. If a particular systems development team needs to know what is in place to enable a particular business process and who within NEF/IS might be responsible for this infrastructure, that team also can drill down on the Web site for this knowledge. When IT management prepares plans for the coming year's IT investments or if it is evaluating a particular technology for inclusion in the NEF complex, the architecture process knowledge store will provide a foundation for informed deliberations. In the case of the NEF/IS site, the domain teams tapped the very best minds within the organization for contributions. Similarly, we included contributions from our external partner providers to supplement internal expertise.

Throughout this process, we made it clear that the domain teams were not responsible for the actual planning and implementation of new technology investments. Rather, they were responsible for providing an informed direction and for the articulation of standards. Their recommendations served thereafter as the foundation for action by IT management, in line with the business needs and financial constraints of the enterprise. Many times, those involved in the architectural process also wear an operational hat. This was certainly true at NEF/IS, where domain leaders also oversaw IT teams and key lines of business. If this is the case, they must do what they can to keep these roles distinct; otherwise, the architecture effort will get mired in the minutiae of project implementation and management issues.

Each domain team, with encouragement from the PMO support team, began the ongoing process of gathering information and converting tacit knowledge into explicit architecture documents. The frameworks provided within the architecture Web site helped this effort along. See Exhibit 5.

Exhibit 5: An Architecture Domain Information Grid

start example

click to expand

end example

The information grid illustrated in Exhibit 5 lays out the status of each technology within a domain category. For my example, I have chosen a view from the desktop and collaboration technology domain. To the far left, the domain team lists each technology product grouping, e.g., Microsoft Office. The team then indicates the minimum requirements for the product in question, as well as the enterprise standard. In the case of NEF, because the home office would often run different products than the field agencies, the form provides space for both options. The grid also allows space for listing product versions under study (i.e., In R&D). Products scheduled to be sunsetted or transitioned are also listed, as are targeted (future) standards. Product citations that are underlined indicate that they are linked to detailed product descriptions and other, more technical information. See Exhibit 6.

Exhibit 6: A Product Information Sheet

start example

click to expand

end example

As part of the ongoing maintenance of an architecture process, the PMO team worked with the domain teams to ensure the currency and comprehensiveness of their respective technology grids and the linked product information sheets. This sort of detail management work aligns nicely with the competencies of a PMO. The author's support team also catalyzed domain team discussion by introducing information about emerging technologies and evolving business requirements. These efforts took time, but within three or four months, key domain team deliverables began to fall into place. Typically IT architect of the process assisted domain teams with grid extensions and on the initiation of applied research efforts. Lastly, as the body of information grew, the architect performed an audit function, keeping the domain teams and IT management apprised of the status and completeness of process deliverables. [9] In turn, these accomplishments helped shape the procurement, sunsetting, and standards decisions of the NEF/IS organization.

[5]In smaller IT organizations, there may not be a designated individual in a formal architect's role. On the other hand, you will find that others perform some aspects of this function as part of their current infrastructure, systems development, or data management assignments. Involve these people in the process.

[6]As the reader will observe, the author has organized his IT architecture efforts around a series of technology domains (e.g., Web and Internet technologies, server and storage technologies, and networking technologies) that draw on the various centers of IT specialization across the enterprise featured in the case study.

[7]Bear in mind that this sort of work is highly rewarding to technologists, especially when they see the fruits of their efforts realized in the statement of enterprise IT standards. Most gladly devote the extra time required, as part of their overall development as professionals and for the privilege of being treated as thought leaders within the organization.

[8]The technical description should be kept to one page. Otherwise, colleagues will not read it. Basic information on this sheet should include product name and version number, the vendor, the domain team responsible for the maintenance of the entry, a brief description of the product, a rationale for the choice of this particular product, a statement on the practical useful life of the product, references to more detailed product information, and, most importantly, the individual or department currently responsible for the care and feeding of the product. See The Hands-On Project Office, http://www.crc-press.com/e_products/downloads/download.asp?cat_no=AU1991, chpt8~1~architecture Web site~example for a complete set of examples of domain team output.

[9]For an example of the standard NEF/IS architecture process audit, see The Hands-On Project Office, http://www.crcpress.com/e_products/downloads/down-load.asp?cat_no=AU1991, chpt8~2~architecture audit~example.



 < Day Day Up > 



The Hands-On Project Office(c) Guaranteeing ROI and On-Time Delivery
E-Commerce Security: Advice from Experts (IT Solutions series)
ISBN: N/A
EAN: 2147483647
Year: 2006
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net