 | Level: Introductory 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
06 Jun 2006 Enterprise architectures rely on a series of tools for implementation and documentation. These tools range from comprehensive frameworks describing the architecture to common-sense documents that describe how to implement it. Whichever tools you use, make sure you also apply a strong dose of communications to cement the relationships that support the architecture.
Can we talk?
So, you're putting an enterprise architecture in place. Good for you! Now that you've decided to take that road, know
that you can rely on a few key tools to help you along the way. In fact, two different types of tools are available --
those that are more formal and those you can build yourself. Formal tools include items such
as enterprise architecture frameworks. Informal tools are a catch-all category that include many things, the two
most important of which are a proper communications plan and an open dialog for application preparation and deployment.
Use the right framework
The right framework can go a long way toward facilitating implementation of an enterprise architecture. Many frameworks are on the market, and all of them have the same main goal: Outline a structure by which complex object
relationships can interact to link people, processes, and technology. For example, The Open Group Architecture Framework (TOGAF) or the Zachman Enterprise Architecture Framework -- supported by the Zachman Institute for
Framework Advancement (ZIFA) -- both provide a matrix that enables you to lay out the interrelationships of the components that help align business requirements with IT services.
The Zachman framework was put together in the 1990s to help provide a model that allowed organizations to identify the relationships between business and IT. (See Figure 1.) John A. Zachman believed it was too
easy for IT to ignore business needs and to create IT for IT's sake. While it's good practice to ensure that there are sound design principles around any IT practice, it's also essential to make sure that all the services and products that an IT infrastructure provides are aligned with the business strategy of the organization. Otherwise, you can end up with a gap that leads to a dysfunctional IT service. In fact, Zachman argues that where the responsibility of day-to-day IT focuses on the hardware and the software that make up its underlying components,
the responsibility of the architecture is to focus on the contents that this infrastructure will hold. It is the contents that help define the architecture. So, you should look to frameworks and models as tools
that help you identify the contents of your systems, and then guide you in the selection and implementation of the components that will support this content.
Figure 1. The Zachman enterprise architecture framework
See a larger version of Figure 1.
Choosing the right framework and learning how the relationships it outlines can help you improve or implement your
own enterprise architecture requires effort. There is no right or wrong framework. A framework is designed
to assist you in understanding the make-up and design of your enterprise architecture. The best way to choose the
framework you'll use to support your architecture is to examine the available models and find the one you have the
most affinity with. Inspect the two frameworks mentioned here, and stick with the one that feels best to you and
your prospective design.
Apply a strong dose of communications
Mountains of information can be, and have been, written about frameworks (see Resources), but
frameworks aren't the only tool your enterprise architecture will rely on. Sometimes, the easiest way to look
at frameworks and identify how they can help is to start closer to home. Frameworks are designed to help align
business with IT, and the best place this process can begin is through dialog. Too few organizations have a
proper dialog between business and IT. It's no wonder, because IT often doesn't have open communication channels within itself.
In fact, one of the most prevalent symptoms of this dysfunction is evident in the way IT puts new applications
in place. Let's look at a simple scenario.
The business has a new requirement. To fulfill this requirement, the IT team decides to put together a new application,
which means that the application developers must open a dialog with business to obtain more detailed requirements.
This phase is where one of the first potential pitfalls of the process can occur: Insufficient requirement definitions will cause the
application to fail because developers won't have a clear understanding of the business need.
The next step for developers is to begin putting the application together. While the requirements issues can cause
major rifts between need and result, this second step is often the source of the most pain in application development
because in most organizations, there is often very little communication between IT and information services (IS).
Developers frequently work in their own world, building their own development machines and environments. When the time comes to put the application into production, often nothing works because the environment used to prepare the application doesn't include all, or any, of the standards and supporting principles that the actual production infrastructure contains. Tempers rise when both IT and IS try to cast the blame for problems that appear when IT tries to get the application to run.
Lack of communication is the real cause for this grief -- grief costing time and money, which could have been avoided through simple communication
principles. In actuality, a communication triangle must be set up among business, development, and IT. (See
Figure 2.) Communications channels should go in both directions, linking IT to development, development to business,
and business to IT, and then back again. Formal meetings should also take place to ensure that nothing is dropped. When those meetings do come together, don’t be afraid to state the real facts. Too many organizations put these
communications channels in place only to end up in worse situations, because the real facts are not brought out
in the meetings. Don’t be afraid to speak up!
Figure 2. The enterprise architecture communications triangle
Cement your relationships
OK, so now you have a framework to assist you, and you have communications channels in place. You're well on your
way to an improved relationship among all the parties involved. But you can still find yourself in a situation
where applications won't work when deployed to production. How do you avoid this? Simple -- by controlling the
environments that used to perform the development.
Developers aren't infrastructure experts, and it isn't really the developer's role to build, manage, and maintain
an infrastructure. That said, developers need a certain amount of freedom to perform their work. The best way to
give them the freedom they need is to provide them with virtual machines (VMs) running on virtual platforms --
platforms such as VMware, Xen, or Microsoft® -- and make sure these VMs are built and constructed according to the
principles you put in place at the infrastructure level of your enterprise architecture.
Development should graduate through a series of environments -- unit, functional, integration, staging, and
pilot/production -- each containing more of the infrastructure components that make up the production environment.
(See Figure 3.) Each level should have a standard entry criterion as well as exit criteria. Specific goals should
be set for applications in each environment, and applications should be contained within these environments until
they meet the goals. By the time an application does make it to production, any operational issues it has
encountered in previous environments should be completely resolved. In fact, if you provide your developers with
the entry and exit criteria, the proper documentation to prepare for each level and proper access to the
technologies contained in each level, you'll greatly facilitate your application integration process. The section,
Environmental description checklist, outlines the components you should provide
to developers to facilitate the integration of their applications with your graduation environments.
Figure 3. Graduation environments in support of application development
Preparation
After you've defined all the key elements that make up the project, you can move to project preparation. In
this phase, you refine budgets, develop the teams that will be involved in the project and assign their
responsibilities. Ensure that communication channels are established among all team members.
Too many organizations make the mistake of involving only development team members at this stage, which leads
to products that are ill-prepared for delivery to production environments and that will lack support, training,
and any other nondevelopment mechanism required for their operation. Because several teams are required
to ensure high quality for the product, each one should have a representative in place at this time. Communication
mechanisms should also include frequent feedback to stakeholders to ensure they are completely aware of both
unforeseen challenges and successes as development proceeds.
Environmental description checklist
The checklist you provide to developers to assist them in the
integration of their application to graduation environments should contain
the information listed here. This checklist is the first step in the
conversation you will hold about the integration of the new application.
Application server requirements
- Name and IP address of the
target server
- Application administrator server
account
- Software requirements:
- Operating system
- Web server
- Development
tools
- Availability requirements
Directory services and security
requirements
- Group names
- Access rights
- User accounts with defined
roles, including roles for the new application
- Service account names with
access rights
- Policy components, if
applicable
- Delegation requirements, if
applicable
Database server requirements
- Logins and access rights
- System administrator group
privileges, if applicable
- Database requirements:
- Database
administrator, if applicable
- Database
name
- Database
size
- Database log
size
- Performance requirements
- Availability requirements
Portal requirements
- Custom templates
- Web components
- Extensible Markup Language (XML)
documents
- Collaboration requirements
- Custom areas
Other environmental requirements
- E-mail server
- File Transfer Protocol (FTP)
capability
- Management server requirements:
- Specify counters
or objects for monitoring new application
- Counters or
objects for Web services monitoring
- Development tools
Documentation
- Installation instructions
- Tested installation
instructions
- Database installation and
configuration instructions
- Application configuration
instructions
- Operational description
instructions
- Disaster and recovery plan
Bring it all together
There is a direct correlation between the success of application deployments and the provision of structured,
standardized graduation environments to development teams. But the provision of these environments must begin at
the infrastructure level and start with a sound understanding of the production infrastructure. Infrastructure,
graduation environments, and development are all pillars of the enterprise architecture -- pillars that will either
support it or make it crumble. So will frameworks.
Frameworks are not simple to follow, but they are necessary tools. If you want your enterprise architecture to succeed,
you must select and rely on a formal framework. With time, you will become as familiar with the framework as you are
with the architecture. Meanwhile, go for short-term gains and start working on the other pillars. Be proactive. Begin
the dialog within your IT teams and bring it to the business level. You’ll see. Problems will begin to disappear, and you’ll soon learn what it means to be agile. Agility in IT -- now there’s a novel concept.
Resources Learn
Get products and technologies
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
| |
