 | Level: Intermediate Danielle Ruest (architectures@reso-net.com), Senior IT Enterprise Architect (EITA), Resolutions Enterprises
Nelson Ruest (architectures@reso-net.com), Senior IT Enterprise Architect (EITA), Resolutions Enterprises
19 Sep 2006 Now that you've supplemented your business architecture with an information architecture, you can move on to updating your existing infrastructure architecture. This update consists of a validation and a possible realignment of the infrastructure to meet the requirements outlined in both the business and the information architectures.
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
|
The evolution of an enterprise architecture
Traditional enterprise architecture designs rely on four core elements: business,
solutions, information, and infrastructure (technical) architectures.
Unfortunately, building an enterprise architecture in this order no longer fits
with reality. Because most organizations today already have some form of IT
infrastructure in place, it only makes sense to design and build the enterprise
architecture from existing elements, recovering and reusing as much as possible
from what's already in place. As a result, you can no longer rely on the
traditional method of enterprise architecture design. In fact, the only
organizations that can hope to build enterprise architectures in the traditional
manner are new organizations that don't have existing elements to recover.
Today's enterprise architecture must use a new process for its design -- a process
designed to adapt the existing and upgrade it to meet new demands. Drawing from
environmentalism's three Rs -- reduce, reuse, recycle -- you can begin to mold
your existing infrastructure into a new system that will grant you the services
you need in a completely new manner. Any modern approach to enterprise architecture
should begin with intangibles or abstract elements, such as the business, followed
by the information architectures, and then move on to the tangible or the concrete,
updating the infrastructure architecture and following that with the modification
of existing development, integration, and operations architectures.
An enterprise architecture is an essential part of any modern IT system. Most IT
environments have been built from the ground up, responding to needs as they're
discovered. As a result, in many cases, the IT environments organizations use
aren't designed specifically to meet business objectives or -- worse -- are
designed to meet the objectives of the IT department itself. The business and
information architectures must be developed to ensure that IT is providing the
right level of service for the organization. These architectures provide IT with
a series of inventories that let the department identify what is and is not
important. They also provide a strong incentive to move to a service
mode rather than to be an entity in and of itself. If your IT department isn't
providing service in a timely manner, look to this new enterprise architecture
process and update each element of your own enterprise architecture. Then, you'll
ready to meet any business challenge.
|
|
These key elements provide the best support for updating the existing architecture.
Figure 1. Ten steps to an infrastructure
architecture
The new vision statement
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.
Security, security, security
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.
 |
Information flows
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.
Architecture standards
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. |
Resources Learn
-
Stay current with
developerWorks
technical events and webcasts.
-
Read
"Enterprise IT
architect: Meet the new kid on the block," by Danielle Ruest and Nelson Ruest
(developerWorks, May 2006) for more information about enterprise architects.
-
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.
-
Get more information about
developerWorks IT architecture.
-
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
About the authors
| 
| | 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. |
Rate this page
| |
