Level: Introductory S. E Slack (sally@sslack.com), Author and business transformation communications consultant, Freelance writer
24 Jul 2007 Every organization has unique business needs, so a variety of factors are
important when planning an enterprise architecture approach for
your company. In this article, examine elements you should take into
consideration when planning a new or revised enterprise architecture.
This series explores several elements that go into the creation of a successful
enterprise architecture. You'll discover, among other things, how to:
- Document as is architectures
- Develop intermediate and target architectures
- Craft an agile enterprise architecture
- Work with system topology and organizational issues
- Monitor the effectiveness of your architectural design
This article begins the series by giving you new viewpoints to consider as
you work with enterprise architecture design and implementation. You'll explore
the importance of aligning business and technical strategies, why communication
skills are so critical to your success, and how you can position yourself as a
trusted advisor in your organization. You'll also examine some helpful tools and
techniques you can use during the process and a few milestones that you should be
aware of along the way.
Skills and competencies
In the planning phases of an enterprise architecture design, there is less
emphasis on actual design skill and more emphasis on using strategic business
skills. As you'll see in this section, aligning the enterprise architecture
properly to the business involves more than ensuring processes are adequately
handled.
Employ business and
technical strategies
When you look up the definition of enterprise architecture, you see that it's
essentially the practice of applying particular methods to the current or future
structure and behavior of an organization. It specifically addresses processes and
information systems, although it can include other things too. The key to creating
a strong enterprise architecture is to recognize that whatever you do, the
architectural design must align closely to your organization's strategic
direction and key goals. What's interesting about enterprise architecture is
that, while it obviously must relate to the information systems in an
organization, the emphasis is actually much more closely tied to business
optimization techniques.
These techniques typically involve looking at enterprise architecture information
technology (IT) design as a technical strategy overlaid on business strategies. If
your organization, for instance, has a business strategy involving reduction of
time to market, then the architecture must support that business strategy through
a technical strategy designed to streamline design, manufacturing, and production
processes. And, since there is never just one urgent business strategy in
an organization, you must conceptualize and create development and operational
models that can not only respond to business needs, but plan ahead for them. Your
design must be a blueprint that can guide business development and decision
making, plus be nimble enough to change course quickly.
As noted in
"Let's talk: Build your enterprise architecture using communication and the right framework,"
the right framework can go a long way toward facilitating implementation of an
enterprise architecture by outlining a structure by which complex object
relationships can interact to link people, processes, and technology. 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 skill in all this, of course, lies in your ability to think in broad enough
terms to encompass all the possibilities for your organization. If you're not
confident about this skill, talk with your superiors about attending more business
meetings as an observer to listen and observe as much as possible. If that's
not possible, ask your supervisor to fill you in on a monthly basis about what's
being discussed at higher levels so you can start to fill in the blanks for
yourself. If you're a supervisor, keep your employees informed as much as possible
about potential corporate direction. You don't have to spill confidential details,
but at least give general information about what you foresee on the horizon.
Communication
Because you're involved in viewing overall processes and systems for your
organization to ensure that everything flows properly, you'll also discover that
making one decision can lead to the need for a dozen more decisions. The
ramifications of changing a simple piece of code can be magnified if that change
impacts multiple departments, for example. This is when you need to sharpen your
communication skills to play mediator as needed or even devil's advocate in many
situations.
The trick to maintaining a level head and getting your point across is to explain
your business reasoning as clearly as possible. Skip highly technical
explanations when addressing nontechnical audiences—you'll just confuse and
overwhelm people with details. Instead, stick to the language of the business, and
you'll find that you get a better acceptance rate for your ideas or concerns.
For example, if you know that a software change request from marketing will make
a piece of software used in sales obsolete, then you need to explain that in those
simple terms. Don't try to describe what the software change will specifically do,
just leave it at something like, "Changing this software will result in an
increased expense for sales. If we don't change it, however, marketing will
continue to have productivity problems that will ultimately be more than twice the
cost of the increased expense for sales."
Speaking in these simple but direct terms does two things:
- It helps your audience understand the problem quickly.
- It helps you resolve the problem quickly.
It might be tempting to show everyone the specifics involved. But if you lose
your audience with technical explanations, you'll never get to what you want: a
resolution so you can finalize your design.
Observation and analysis
Speaking of communication, you're usually asked to fix problems, right? Well, the
more you can show others you can communicate in their business language instead of
IT-speak, the more they'll start pulling you into planning-stage discussions. This
puts you in the role of a trusted advisor who can observe and analyze business
strategies and decisions as they occur. This observation and analysis stage is
critical to helping make your job easier.
That's because you will know exactly what the business is considering potentially
months before you would normally find out about a proposed change. You'll be able
to better understand the resource issues throughout the organization, the impact
any changes will have, and even which types of test cases should be run prior to
deployment. You'll know everything because you'll be one of the decision makers!
If you aren't being asked to join in planning discussions, get to the current
decision makers and ask what's going on in their area. Offer to attend their next
meeting, and then simply observe when you attend. Without being asked, begin
analyzing some of the concepts being tossed around. Ask to attend another meeting,
and then softly toss in your analysis of the current plans wherever it's
appropriate. The idea is to become an ally or trusted advisor, as mentioned
earlier. As people begin to recognize that you are trying to help instead of
hinder their plans, they will be more open to your ideas and suggestions.
Tools and techniques
When you're attempting to plan for the future with an architecture, sometimes the
most critical tool you can have is a solid understanding of the past. How your
organization thinks, acts, and reacts during good times and bad can help you
determine how to approach your design.
Understand the
organization
One technique that should be on any enterprise architect's list to conquer may
sound simple, but it's actually pretty complex: understand the organization. This
doesn't mean understand what industry your company is in or get a good idea of how
the organization is run. It goes far beyond that.
Understanding an organization means understanding its culture, values, norms, and
principles. For example does your organization celebrate Founder's Day every year?
If it does, do your research on who founded the company, what his or her ideals
and goals were, and how those ideals and goals are kept alive from year to year.
Maybe your company was recently acquired by a company from another country. Do you
understand that country's business customs? For example, China has very different
business customs than the United States; in the Chinese culture, disagreements are often
expressed in nonverbal terms, whereas in the United States
disagreements are expressed verbally.
These types of cultural issues give you subtle—and sometimes not-so-subtle—
clues about what an organization values most (integrity? profit? honor?) and how those
values impact the business environment. Knowing this information puts you in the
driver's seat when you create or update an enterprise architecture. You have a
better feel for which changes will be readily accepted and which ones you need to
fight for.
You also have a better understanding of stakeholder concerns. If you know, for
instance, that the stakeholders in the enterprise architecture are mostly
concerned with maintaining traditional business methods over trying new
approaches, you don't waste time coming up with innovative approaches that could
ultimately change a traditional business method.
If you haven't been paying much attention to these kinds of things, it's not that
difficult to get up to speed quickly. Try contacting your organization's
communications or public relations department and request documents about the
company's history. Or read the company newsletter the next time it lands on your
desk. While some of the information might strike you as mundane or even silly,
events and traditions are always covered in those publications. Ask long-term
employees about the changes or lack of changes they've seen over the years. Pay
attention during meetings. Do executives fight with one another openly, or are the
battles less obvious? What kind of management style is used at your company?
Open-door policies indicate a willingness to listen to all levels. The lack of
such a policy indicates that company leaders prefer to stick to a hierarchical
approach to getting things done.
The right approach
How many projects have you been on where the thinking and planning was conducted
in a top-to-bottom approach? In this kind of approach, top executives decide a
change needs to be made, lower executives agree, and then those from lower rungs
in the organization are pulled in as needed to make the change happen. That's the
way most changes occur. But sometimes it can be just the opposite: a low rung in
the organization requests a change, and the request moves all the way up the
ladder to the very top before anything happens. What's usually missing in both
scenarios is the horizontal approach.
Thinking horizontally means that different levels of the organization work
together to decide what changes need to be made. The breadth of the change and its
impact on the organization is considered above everything else, whereas the depth
of the change is usually the focus in vertical top-down or bottom-up approaches.
Remember the comments earlier about understanding your organization? If you have
done your homework, you have a good idea whether your company is partial to using
one approach over another.
The optimal approach in most cases is to think both vertically and horizontally.
While digging deep into the organization with your design can encourage
innovation, ensuring that everyone in the organization is reached can breed
stronger acceptance of the design. There is no right or wrong way to approach your
design, but it's worth doing some research on the concept of horizontal and
vertical approaches to determine which one is better for you or if you should use
both.
Again, understanding your organization comes into play with this technique. You
know you've got the right approach when you get feedback from across the
organization that your plan appears to be a good one. Don't be afraid to talk to
as many people as possible during this portion of your design. The more people you
elicit feedback from, the better equipped you are to find the right approach for
your organization.
Milestones
Milestones are a bit murky when you're delving into elements of enterprise
architecture beyond design and IT. They aren't necessarily milestones that can be
measured, so you need to be a bit creative and thoughtful as you take a look at
the ones I've outlined here.
Implementing change
With any enterprise architecture design, there are changes that impact the
employees in the business. It's critical, then, that you partner with your
company's communications team to ensure that the changes are not just understood,
but adopted throughout the organization. Change isn't implemented in a single
step. It's implemented in three key steps:
- Preparation
- Acceptance
- Commitment
These steps are typically handled through continuous communications that stack
key messages on top of one another.
Let's face it, you and others work for months to ensure the design you create
deploys seamlessly to the organization. But everyone else beyond the deployment
team is completely unaware of the changes that are about to occur. They are in
what's known as the unawareness phase. Before you can even begin to think about
deploying new software or hardware that impacts the organization on a broad basis,
you need to prepare the organization by sharing information about the change and
why it's necessary. Those affected need to know what to expect and when.
When the organization is adequately prepared for the changes that are coming, you
can move to the next phase of implementing change: helping people accept the
change. Just because they are aware of change doesn't mean they will like it. The
acceptance phase is designed to help build a positive perception of the company's
direction. It's only after this phase that people will accept or buy in to the
change and begin to embrace it.
Your role in implementing change is critical. Without your knowledge and input,
the communications team can't even begin to share the proper information with
employees. Without it, employees won't accept the changes that occur. And if
employees don't embrace the changes you make, you've got potential failure on your
hands.
The IBM® Rational® product suite has a variety of tools that can
assist you with organizational change. The developerWorks article
"Organizational change in the Internet age"
provides good insight into this topic.
Achieving value
This milestone involves a little self-reflection. It can be used at any point
during the process, although the most obvious place is after deployment. Ask
yourself the following questions:
- Does this plan truly achieve the business value I anticipated?
- Are people actually working more effectively?
- Is the business getting the information it needs to be competitive?
Value is a nebulous term. It's often based on perception. Do people think
they are getting what they expected out of your design? If so, then it's probably
achieving at least the majority of the value you anticipated. You need to do some
surveying, however, to find out. Don't rely on the people who helped you implement
the design. The chances are good that they think the design has value!
Instead, use that communications team to conduct some surveys, or make some random
phone calls yourself to employees or first-line managers.
These are the folks who can really tell you whether the design has achieved any
value for them. If their jobs are easier, if productivity is higher, if down time
is reduced, then you get positive reinforcement about the design's value. Don't
panic if you hear less than stellar reports, though. Use those as lessons learned,
and apply them as the basis for upcoming upgrades. Remember, users are often reluctant to embrace new tools at first. If you’re hearing lots of fears about the technology in user responses, work directly with your education and communication teams to see what can be done differently the next time around to allay those fears through training and targeted information before the next design deploys.
Summary
This article gives you some new viewpoints to consider as you work with
enterprise architecture design and implementation. Your organization has unique
business needs, so it's important to recognize which of these viewpoints are of
value to you and which aren't. In general, the viewpoints outlined here can work
nearly anywhere. All it takes is your willingness to approach enterprise
architecture with a new attitude. Stay tuned for the next installment in this
series, which addresses the
documentation of current (or as is) architecture.
Resources Learn
Get products and technologies
Discuss
About the author  | 
| | S. E. Slack is a freelance writer and author with more than 16 years of experience in
business writing. She has also been an executive and business transformation
communications consultant to IBM, Lenovo International, and State Farm Insurance Companies. She is currently writing CNET Do-It-Yourself Digital Home Office Projects: 24 Cool
Things You Didn't Know You Could Do (McGraw-Hill) and is the author of six
other books. Contact S.E. Slack at sally@sslack.com. |
Rate this page
| 
