To serve and protect. No better motto can serve as the vision for an infrastructure architecture. This simple phrase encompasses everything that is and should be in an infrastructure architecture -- an architecture designed to provide all the required services outlined in both the business and information architectures in a completely secure and stable manner.
Traditional enterprise architecture designs tend to focus on the creation of the solutions, or development, architecture before the creation or design of the infrastructure architecture (see "The evolution of an enterprise architecture"), but because most organizations today already have an infrastructure of sorts in place, it seems redundant to design the solutions architecture first, then follow with the infrastructure architecture. Therefore, we believe that at this stage in the elaboration of their enterprise architecture, organizations should update or realign their existing infrastructure so that it can closely match the requirements outlined in the two previous architectures. In addition, because the infrastructure already exists to some degree, this particular architecture should focus on other areas of the architecture design process (see Figure 1). In particular, this architecture should focus on:
- Fulfillment of a new vision statement
- Information flows for the architecture
- Architecture standards
These key elements provide the best support for updating the existing architecture.
Figure 1. Ten steps to an infrastructure architecture
Infrastructure architectures focus on technologies and therefore must be specific in nature. It doesn't matter whether you use proprietary or open source technologies; what does matter is that you choose something and stick with it. In fact, we highly recommend that you use a homogeneous technological mix as possible, especially if you're a small- to medium-size shop. It is, of course, arguable that use of a heterogeneous technological mix -- for example, using Microsoft® Windows® for some services and relying on open source technologies for others -- may provide a more secure infrastructure. But in our experience, this is often not the case because of the difficulty of gaining high-level expertise in a vast array of technologies.
Generally, the more technologies you mix, the less expertise you'll have in each. Remember, the new motto is To serve and protect: This means that you must provide the right service on an ongoing basis, and you must ensure that it's secure at all times. So, if you want to fulfill this motto and your shop is a small- to medium-size organization, stick to one set of tools and learn them to the best of your ability. In most cases, doing so provides the best possible level of security. If your organization is larger and you have a vast number of information technology (IT) resources, especially in the form of personnel, go ahead and mix and match technologies, if you wish. You may achieve better security in the end. But in the meantime, you won't be able to ensure that all your staff members are familiar with all the components of the infrastructure.
In addition to the notion of IT as a service (see the link for "Let's talk: Build your enterprise architecture using communication and the right framework" in Resources), the vision for the infrastructure architecture must focus on the word protect. This means that infrastructure is responsible for security throughout the IT elements of the organization; in fact, infrastructure must work closely with other divisions of the organization to fulfill its mission as described later on. Some may argue that security is a discipline in and of itself; but in effect, it's an element of the infrastructure because of the far reach infrastructure has over IT in any organization. That's right. Given its position in the enterprise architecture workflow, infrastructure builds the foundation of all IT services, and everything -- development, integration, and operations -- flows from what you implement at the infrastructure level. Therefore, infrastructure must include a strong element of security; otherwise, no services will ever be secure.
For example, while development is responsible for security to some degree, it is infrastructure that has final responsibility, because after a developed product is in production, it falls within their purview. As a result, the integration architecture, which follows the elaboration of the development architecture, is important: It is the architecture that ensures a tight link between infrastructure and development, making sure all architectures respect the standards that the infrastructure outlined in the first place. In addition, infrastructure is responsible for maintaining the operational environment as well as the integration environments, as will be outlined in the operations architecture. Those responsible for infrastructure must maintain proper levels of each software and hardware component that make up the infrastructure, applying patches in a timely manner and ensuring that all aspects of a secure infrastructure are in place -- antivirus, anti-spam, and anti-spyware software, and so on. This is why the workflows, policies, and standards of the infrastructure architecture are so critical to the organization.
Because of its unique position within the enterprise architecture, infrastructure must develop some key information flows with other core divisions in the organization. For example, because infrastructure is responsible for the IT elements of security, it must have a strong relationship with the physical security division to ensure a continuum of security at all levels of the organization. This idea supports the creation of a defense-in-depth approach that helps provide security in layers, making systems more and more difficult to penetrate based on the information type they're designed to protect. This is one more reason why the information architecture must be prepared before infrastructure.
Infrastructure must also have strong relationships with business, feeling its pulse on an ongoing basis to ensure that the services it provides are the right services at the right time. In addition, infrastructure must have the proper structures in place to react when business requirements are expressed; ideally, infrastructure can be proactive about upcoming business needs and have the proper hooks in place ahead of time so that when a need is expressed, the resulting service can be in place in a short period of time. This level of agility is one of the main objectives of the infrastructure architecture.
Finally, infrastructure must have strong workflows with development. In fact, development must draw its principles and architectures from infrastructure, because you cannot change infrastructures each time you must put a newly developed solution in place. Of all the components of the enterprise architecture, the infrastructure architecture must have the highest level of stability, because it's the architecture upon which the business relies.
To create a flexible and agile infrastructure, you must rely on standards -- not necessarily the standards of the industry, though of course, they are applicable and can be derived from tools such as the IT Infrastructure Library (ITIL) -- but rather standards put in place in your organization that your personnel will learn to rely on to provide service to the business. Three core principles drive these standards, defining and delimiting how IT services are delivered to support evaluation of the quality level of the service being offered. These standards, of course, must always be in line with the requirements of the organization's mission as defined by the business architecture. These principles rely on the concept that computers and computer systems are appliances designed to support productivity within the organization.
These principles are:
- Standardization
- Rationalization
- Certification
Standardization is at the core of any cost-driven delivery of IT service. Standardization means that everything is the same. Of course, you can't take this definition literally. In IT, standardization means that at the core of all IT services, you will find a single and unique approach. If everything is the same at a given level of the IT infrastructure, you can ensure consistent service delivery. For example, ensuring that all the computers in your organization use the same operating system with the same level of service pack greatly facilitates the repair process for your support personnel, because they always know the starting point of any problem-solving situation. They can also devise and prepare standard responses to the most common problems, thus reducing problem resolution time and cost.
Rationalization helps support the standardization concept within IT. By rationalization, we mean a reduction of diversity. This reduction primarily focuses on the tools in use within the IT structure. Instead of selecting a tool because of familiarity or personal preference, you choose it because of function and feature set, thereby ensuring that information flows are supported within the entire corporation because everyone uses the same tools to create it. Rationalization also means running through the entire gamut of tools currently in place and removing duplicate or superfluous tools. Finally, it means that the rationalization process is ongoing and applied each time a new tool selection process begins.
Certification addresses the methods put in place to prepare tools for deployment. By introducing a certification process before deploying hardware or software technologies, organizations can take proactive measures to ensure stability. Standardization, rationalization, and certification go hand in hand in the definition of IT quality of service. They are also the driving principles that support the implementation of standards in IT. These standards must address the breadth of the IT infrastructure. See the table in the appendix for a sample list of standards titles and categories.
If you don't implement these principles and standards during elaboration of the infrastructure architecture, the organization is likely to face the following problems:
- Difficulty maintaining and updating the corporate network: Too many products mean multiple zones and levels of expertise within IT. Some products will be well known and thus well supported; others won't be because of a lack of knowledge or support resources.
- Most support situations require one-on-one relationships: Because diversity is the key, each problematic situation must be diagnosed by itself and cannot be related to other situations occurring in the network.
- Information sources will be disparate: If every person chooses the way in which he stores and produces information, only that person will have access to it. Corporate-wide integration of information sources will be impossible.
- If diversity is a factor, it's impossible to manage and administer distributed systems remotely: How complex do you think the implementation of a tool designed to support complete diversity will be?
- If diversity is a factor, it will be extremely difficult for the network to evolve and change when new and revolutionary technologies are introduced in the marketplace: The cost of tracking the evolution of diverse products will limit the IT productivity of the organization.
- If diversity is a factor, it will be impossible to aim for information sharing through internal development: Developers will follow their own guidelines, and each internal application will be an island.
- Reliability is difficult if not impossible to achieve: A computer system that must host a plethora of products is much more difficult to design and support than one that includes only a few specific tools. Stability and reliability are difficult to achieve when diversity is a factor.
Problems are expensive, and it simply doesn't make sense to live with these problems if you don't have to. Design your infrastructure architecture so that you can avoid all these problems and improve your productivity at all levels. Your personnel will then be able to focus on their tasks and won't be sidetracked by issues that simply shouldn't exist in your network.
Appendix: Essential infrastructure standards table
Table 1 outlines a sample of the standards required to implement and support an organization's enterprise architecture effort. Each standard is clearly identified, numbered, and grouped in sections based on area of activity. Five areas of activity are covered here:
- Generic covers general standards affecting every component of the network infrastructure.
- Identity management services covers the conception, use, and management of identities within the organization.
- Management & administration covers the management and administration of the network infrastructure.
- Use & operation covers usage, interoperability, and operation of the services that the network offers.
- Certification covers the preparation, use, delivery, conception, and operation of hardware and software components within the network.
These essential standards comprise a list of rules and guidelines by which IT can begin the standardization process and globally integrate the network into a new infrastructure architecture. For each element covered in this standards list, each standard must be clearly described according to the structure displayed in Figure 2.
Figure 2. The structure of each infrastructure standard
For brevity, only the standard title and the standard category are outlined here. Organizations should add their own standards definition, justification, implementation guidelines, management rules, and implementation impacts according to their specific situation.
Table 1. Essential infrastructure standards
| Number | Title | Comment |
|---|---|---|
| Generic standards | ||
| 1. | System title and version number | Every system image must be named. |
| 2. | Minimum hardware requirements | Systems must meet or exceed minimum requirements. |
| 3. | Homogeneous network for all points of access | Network components should be homogenized as much as possible. |
| 4. | Unique kernel: Computers | Systems must be constructed from a single image. |
| 5. | Unique kernel: Servers | Systems must be constructed from a single image. |
| 6. | Ongoing system maintenance | Systems must be maintained on an ongoing basis. |
| 7. | Computer "Intelligent" file system | All corporate data must be protected, even on computers. |
| 8. | Buy before build | Limit custom development wherever possible. |
| 9. | Industry best practices | Rely on industry standards as much as possible. |
| 10. | Manufacturer best practices | Partners should provide best practices for implementation. |
| 11. | Component rationalization | Rationalize wherever possible. |
| 12. | Certification process | Ensure that standards are maintained in all builds. |
| 13. | Secure all points of access to the network | All network entry points are secure. |
| 14. | Standard operating procedures (SOPs) | Use SOPs to limit operational diversity. |
| Identity management services | ||
| 15. | Structured identity services management | Provide structured identity services to the user community. |
| 16. | Directory-enabled application evaluation process | Evaluate all applications that interact with the directory. |
| 17. | Protect core directory services | Maintain a high level of security for core services. |
| 18. | Site structure and management | Properly structure the provision of directory services. |
| 19. | Directory replication management: Quality of service | Properly structure the directory replication services. |
| 20. | Directory service service-level agreement (SLA): Quality of service | Ensure high availability of directory services. |
| 21. | Name space naming standards | Use proper fully qualified domain name (FQDN) names at all times. |
| 22. | Directory structures | Ensure that users get a single view of all directory services. |
| 23. | Organizational unit (OU) attribution | Create and assign OUs for specific purposes only. |
| 24. | Delegated directory object management | Use delegation to manage directory services. |
| 25. | The directory as information source | Populate directory fields for better identity management. |
| 26. | User information directory | Provide a single source of user information. |
| 27. | Shared folder information publication | Populate shared data sources with appropriate information. |
| 28. | Computer object information publication | Populate computer objects with identification information. |
| 29. | Shared printer information publication | Populate printer objects with identification information. |
| 30. | Directory integration of corporate applications | Integrate corporate applications with the directory, if possible. |
| 31. | Directory-enabled application delivery and attribution | Rely on the directory to manage application access. |
| 32. | Policy management | Use policies to manage service delivery. |
| Management & administration | ||
| 33. | System identification standards | Properly identify all systems. |
| 34. | Unique network protocol | Rely on a single network protocol. |
| 35. | Limitations on computer resource sharing | Provide centralized IT services to the community. |
| 36. | Operating system installation methods | Unify operating system installation methods to reduce diversity. |
| 37. | Non-kernel application management | Assign extraneous applications per user role. |
| 38. | "Silent" application installations | Install all applications without user interaction. |
| 39. | Self-healing applications | Ensure that all applications support self-healing at all times. |
| 40. | Mobile and stand-alone computer installations | Provision stand-alone systems with the same capabilities as connected systems. |
| 41. | Client-server application management | Deploy client-less applications as much as possible. |
| 42. | Unified logon scripts | Use a single logon script. |
| 43. | Electronic messaging configuration | Protect the criticality of e-mail systems. |
| 44. | System basic input/output system (BIOS) protection | Protect systems from tampering. |
| 45. | Secured local system configuration | Secure all systems from tampering. |
| 46. | System access rights and permissions | Control system access rights to maintain stability. |
| 47. | Local system file security | Document systems file security. |
| 48. | Identical logical disks: Computers | Standardize system construction. |
| 49. | Identical logical disks: Servers | Standardize system construction. |
| 50. | Local disk root structure | Standardize system construction. |
| 51. | Local tree: Software | Standardize system construction. |
| 52. | Local tree: Data | Standardize system construction. |
| 53. | Reserved local disk space | Reserve disk space for corporate operations. |
| 54. | Dial-up networking | Provide virtual private network (VPN) access for remote systems. |
| 55. | Standard network map | Standardize the network map. |
| 56. | Mirroring process: User data and profiles | Protect user data at all times. |
| 57. | Communication tools to users | Provide a standard set of communication tools. |
| 58. | Remote control policy | Publish the remote control policy. |
| 59. | Software delivery policy | Publish the software delivery policy to maintain compliance. |
| 60. | Asset management and inventory policy | Perform ongoing inventories to maintain compliance. |
| 61. | Self-service application installation and management | Provide self-service tools to users. |
| Use & operation | ||
| 62. | Terminal service-mode applications | Run applications remotely, if possible. |
| 63. | Preference for connected server applications | Support service-oriented architecture (SOA) applications. |
| 64. | Requirements for third-party applications | All applications must meet minimum criteria. |
| 65. | Virtualized applications | Virtualize applications whenever possible. |
| 66. | Non-certified application support | If applications cannot be certified, limit their support. |
| 67. | Graphical logon scripts | Avoid text-based windows as much as possible. |
| 68. | Multilingual kernel and regional parameters | Provide multilingual support wherever it is required. |
| 69. | Complete application installation | If local installations are required, provide the complete application. |
| 70. | Shared computer use policy | Limit the use of generic accounts. |
| 71. | Secure access to computers | All systems require logon identification. |
| 72. | Encryption of personal data | Encrypt personal data wherever practical. |
| 73. | Dictionaries and enabled languages | Provide proper dictionaries to all staff members. |
| 74. | Mission-critical and mission-support applications | Secure critical applications on a per-user basis. |
| 75. | Presentation layer design | Ensure that all systems use the same interface. |
| 76. | Call center and help desk access | Ensure that users have easy access to support mechanisms. |
| 77. | IT/Information systems communications to the computers | Put a proper communications mechanism in place for users. |
| Certification | ||
| 78. | Exceptions to the certification process | Limit exceptions to certification. |
| 79. | Certified hardware and drivers | Certify hardware and drivers before introducing them into the network. |
| 80. | Certified in-house development | Certify all in-house development. |
| 81. | User development | Provide proper controls and support to user development efforts. |
| 82. | User application delivery | Provide support for delivery mechanisms of user-developed applications. |
| 83. | Development toolkit | Provide a single, unified development toolkit. |
| 84. | Application code signing | Sign all applications to authorize them in the network. |
| 85. | User policies and system strategies | Perform policy-based administration as much as possible. |
Learn
-
Stay current with
developerWorks
technical events and webcasts.
-
For more information about enterprise architecture frameworks, read
"Let's talk: Build
your enterprise architecture using communication and the right framework," by Danielle
Ruest and Nelson Ruest (developerWorks, June 2006).
-
Learn more about the governance model in enterprise architecture: Read
"Manage the
unmanageable," by Danielle Ruest and Nelson Ruest (developerWorks, May 2006).
-
See "Exploring
IT architecture disciplines, Part 1: Build an enterprise architecture" for more
information about enterprise architectures.
-
Learn more about the IT Infrastructure Library (ITIL) at the
ITIL home page.
-
Learn how configuration management can help resolve compliance issues. Read
"How to Control Your
Infrastructure with Configuration Management," by Nelson
Ruest and Danielle Ruest (RedmondMag.com, June 2006).
Get products and technologies
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Discuss
- Participate in the discussion forum.
-
Participate in developerWorks blogs
and get involved in the developerWorks community.
Danielle Ruest is a senior enterprise IT architect (EITA) focused on people and organizational issues for large IT projects. Danielle has been involved in the design and support of complex collaboration implementations, including deployment of technologies for e-mail, team sharing, and secure instant messaging. With her partner Nelson Ruest, she is the author of Preparing for .NET Enterprise Technologies, (Addison Wesley, 2001). and Windows Server 2003: Best Practices for Enterprise Deployments (McGraw-Hill Osborne, 2003) and participates in many webcasts and conferences. You can reach Danielle at architectures@reso-net.com
Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network, computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at architectures@reso-net.com.
