Planning Technical Architecture

 

by Waleed S. Nema

Summary: The need for technical architecture planning is well known to managers, auditors, and operational staff in this highly demanding and changing information age. Business drivers for this need include aligning IT with the business and controlling service levels and expenses. This discussion summarizes the first experience of creating an infrastructure Windows Server Architecture (WSA) two-year tactical plan for a computer operations department. Technical architecture is defined in addition to coverage of the deliverables and challenges involved.

Contents

Giving It Life
What It Is and Isn't
Tactical Plan for the Windows Server Architecture
Documenting the Plan
About the Author

The discipline of planning technical architecture has only become more popular recently. Therefore, it is not well understood because of lack of experience, training, and even literature. Technical architecture planning, when done correctly, tries to open all aspects of the existing environment and map them to a business-consistent desired state. It tends to create a wide range of questions and issues some never thought of before: some political, some business, and others. As you try to clarify the vision and scope of architecture planning, you may find resistance because of unclear understanding or hidden agendas. You may even have resistance because of who you are or where you're coming from.

Assuming the vision and scope of architecture planning are agreed upon is no guarantee for keen, open, and full participation on the part of operations staff. The benefits of disclosing information must outweigh the cost of revealing soft spots and vulnerabilities that only operational staff know about. Once the planning cycle is over and it is proven that participation is rewarded by allocating budget and resources, only then can you expect more participation in subsequent cycles. Being at the disadvantage of the first one, you're going to have to make the message very loud and clearly stated by management. To be successful, management must clearly outline the benefits to architecture planning from the start.

As you see, you have your fair share of challenges just getting the architecture planning process started, more challenges maintaining participation from operational staff, and challenges obtaining support from management. And if you follow the model of supervising follow-up action plans, as described later, you may appear as a cop or auditor.

The only way for this effort to be successful is to show and prove good intentions. Management, which usually gives the directive for this activity, along with the architecture team must convince staff that this activity isn't about exposing them but rather about creating a better, more efficient operating environment that better serves the business. In the end, everyone wins but at the expense of accepting change and letting down defenses and barriers.

Giving It Life

Above all, architecture team members are facilitators. They must work with operational staff to understand the existing environment. As a matter of fact, operational staff should be the architects for the existing environment because they know it better than anyone else. The architecture team must work with business and other corporate planners to bring in the business strategy and direction that IT should be aligned with. The team must work with management to understand tactics, constraints, and gain support. They must also bring in the industry best practice perspective covering framework, technology, process, and people. The architecture team needs to bring all of that together in a workable, realistic plan.

Architecture and planning generally give a view of a future state that translates some kind of need or wish. If we're talking about a house, for example, an architect develops a detailed plan that meets the guidelines of the owner. If we're talking about a model to be used in a development community, then we're also talking about a standard to be followed to maintain a specific budget and general look. The owner's guidelines and requirements in this sense could also be thought of as a standard for the builder. To bring an architecture blueprint to life, a rather complex construction project plan must be devised and followed. The beauty of the house on paper means nothing until the owner can see it in real life.

Therefore, it makes sense to think of architecture planning as a process that translates a set of guidelines and requirements into standards that builders can implement. If a building already exists, architecture means projecting new requirements and enhancements to the existing structure.

The technical world has not learned enough from the well-established construction industry. The roles of owner, architect, builder, and inspector are well known in the construction field but not equally so for the technical field, particularly the inspector's role. In the construction industry, the builder is almost always a different entity than the architect. The inspector could also be an independent entity but is frequently the same as the architect, both of whom act on behalf of the owner and must approve the builder's work.

We technical people need to empower and enable architects to take on the role of inspecting and supervising the implementation of architecture plans. In IT, project sponsors frequently are the owners. Architects should act on their behalf and assume whatever authority is required. With this new twist, not only is architecture planning responsible for producing blueprints and standards but it also must be responsible for overseeing the implementation of the architecture plans.

Since architects represent executive sponsors in this model, they need to be aware of the business case and must identify action item recommendations and set priorities accordingly. The executive sponsor is ultimately responsible for the architectural process and its successful implementation.

To summarize, architecture planning must address these five aspects: standardization, enhancements, implementation supervision, business-driven priorities, and management follow-up; and we can define it this way: technical architecture planning is a process sponsored by executive management that translates existing business needs, challenges, and wishes into a prioritized set of standards, plans, and action items, which recommend and oversee service enhancements leading to better customer experience and operational excellence.

What It Is and Isn't

Technical architecture aims to raise the capability and maturity of service. It is about models, standards, and action (enhancements). It is a high-level solution specification but is not a design specification. Solution specifications are like setting the budget and lot size of a house model in a development community rather than getting into its layout specifics. Once approved, follow-up design and implementation projects are usually born for new services or large-scale enhancements.

Technical architecture is not simply a Visio diagram of file server configurations. Architecture is, whether a logical file server name space (such as Distributed File System) is used; whether a centralized or distributed management model is followed; or whether a free-access, shared-hosting model is used for databases or Web sites. Those types of decisions have far-reaching consequences and thus are architecture-level decisions.

Technical Architecture is most certainly about process. As a matter of fact, it is frequently the process, not the technology that can make or break a service. Processes often involve people issues that imply politics and sometimes are the most dangerous aspect of all! Worse yet is when the system doesn't have checks and balances for working with such issues.

Tactical Plan for the Windows Server Architecture

This outline is a partial table of contents for the Windows Server Architecture (WSA) tactical plan.

Introduction
Disciplines
   Web hosting services
      Executive summary
      Introduction
         Background
         Business drivers
         Objectives
         Scope
      Solution concept
         Service architecture
            MOF optimizing
               Service model
               Service offerings
               Service/operational-level commitments
               Service requests
               Quality assurance
               Team model
               Support services
         Technology architecture
            General
               Corporate application strategy
               Definitions
               Trust zones
               Hosting profiles (deployment patterns)
               Architectural guidelines
            MOF changing
               Dependencies management
               Production control
            MOF operating
               Monitoring
            MOF supporting
               Incident/problem management
               Problem isolation
               Enhanced error reporting
            MOF optimizing
               Security strategies
               Business continuity strategies
      Action plan recommendations
      Appendix
         References
         Diagrams
   Other services (file and print, directory, data)
Server road map
Consolidated deliverables
   Infrastructure
   Development
   Policies and processes

Technical architecture is about measurement. People must feel that measurements are created to help them, not to expose them. Management must make their intentions crystal clear to gain the trust and full buy-in from staff. Only then do we have a chance for anything to work. Management must communicate the reasons for measurement, which include realization, or the awareness of how far off we are, improvement to reach targets, and estimation of what's required. Management must also avoid public embarrassment by putting a positive spin on public reporting such as "percentage improvement over last period," while keeping absolute reporting internal until the numbers are close to the Key Performance Indicator (KPI) targets. Management must prove good intentions either by getting the required resources or by accepting slower progress and less-impressive results.

Technical architecture is about automation. That's the key to efficiency, deterministic processes, and stability. Automation gives operations staff more time to focus on analysis and optimization, which are the basis for service enhancement.

Technical architecture is also about monitoring. The only way to be in control is to constantly look at the road and the gauges. Architecture gives you a road map and makes sure you see the right gauges. It also helps you create an alert and escalation system—possibly an automated corrective reaction.

Architecture is a continuous cycle as assured by many frameworks such as Microsoft Operations Framework, Deming's cycle, and the COBIT/Management cycle. It is basically a planning phase followed by monitored operations, the learning of which feeds optimization and enhancements into a new cycle.

Documenting the Plan

The main body of the Windows Server Architecture (WSA) tactical plan is in the functional area disciplines such as Web hosting services, directory services, and so on (see the sidebar, "Tactical Plan for the Windows Server Architecture"). The server road map applies to specific technology changes in the tactical period. The last section, consolidation deliverables, collects action plan recommendations from all sections and categorizes them in three areas to help follow-up projects: infrastructure, development, and policies and processes.

The architecture's main body of each discipline service—Web hosting services, directory services, and so on—is in the solution concept section, which is divided into service and technology architectures that are in turn based on the Microsoft Operations Framework (MOF). The introduction includes the background, business drivers, objectives, and scope sections, and it sets objectives such as the number of 9s for high availability, among others.

The executive summary is a one-page summary of as-is, to-be benefits, goals, and approach in addition to the most significant action plan recommendations.

Table 1. Sample of action-plan recommendations

Section Priority/
deadline
Objective Resources/
skills
Work
estimate
Success
metric
  Service model        
3.x Priority A
Q4 2005
Publicize the Internet Service Provider (ISP) hosting model WHG   Publish document in SLC, OLC, and new service request terms and conditions.
  Monitoring        
3.y Priority A
Q2 2006
Monitor Web sites/servers for downtime, performance, and optimization WHG   Assign a monitoring attendant role to a named person who will be accountable for attending to all monitoring console events.

Explore MOM 2005 new features including IIS Management Pack, and Web sites and Services MP.

Enable text-messaging and escalation for critical errors such as server-down.

  Production
control
       
3.z Priority B
Q4 2006
Build a Web site publishing tool Consulting assignment   Engage in a development contract that will build a Web site Publishing Tool as defined in the existing prototype.

Action plan recommendations are probably the most important summary of all the solution specifications and success metrics because operating staff set priorities and deadlines and indicate in the resources/skills column if they can do it themselves or they need it to be contracted out (see Table 1). Establishing architecture planning as a discipline and a role has paid off even before finishing the first tactical cycle. It is a delight to see the completion of the plan and the start of action. This result does not happen without cost or effort and is dependent on teamwork among all players.

About the Author

Waleed Nema is the team lead for Windows technical architecture planning, computer operations department at Saudi Aramco. For the great success of this project, Waleed would like to thank his management, operational staff, and architecture team.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.

© Microsoft Corporation. All rights reserved.