 | Level: Introductory S. E Slack (sally@sslack.com), Author and business transformation communications consultant, Freelance writer
10 Apr 2007 Plan for growth in your application architecture by learning how to focus on
customer-centric business strategies using scalable and adaptive thinking.
Many elements -- modeling, requirements, design, process, performance, and
others -- go into the creation of a robust application architecture that can withstand
the test of time. One aspect of application architecture, however, is sometimes
overlooked because it's not a quantifiable piece of the overall process: growth. Your
company, your industry, business strategies, customers -- all these areas will grow and
change over time.
As you design your application architecture, planning for growth is as critical as any
other aspect in front of you. In this article, you'll learn the skills,
competencies, tools, techniques, and milestones that can help you effectively create an
architecture that will be as relevant tomorrow as it is today. As you read this article,
close your eyes and imagine yourself in your customers' shoes, regardless of whether
those shoes are worn by business unit employees, vendors, suppliers, or business
partners.
Skills and competencies: Scalable
and adaptive thinking
When you think of the term scalable, you probably think of the applications
you want to use in your design and whether the those under consideration can handle
an increase in the number of users. Then, perhaps, you think about how those
applications can be used in different areas of your organization. Perhaps you've
even thought about how to ensure that users have easy access to information through
interfaces that are simple to navigate and connect to. But have you thought about
what will happen six months from now? In a year? In three years?
No matter how close to perfection your application architecture is, it won't be that
great in a year. You haven't done anything wrong; it's just the way it is. For
example, assume that you have rolled out the most up-to-date accounting application
architecture the world has ever seen. Users love it, the company is getting the
information it needs to make strategic decisions, and you're happily planning your
next project. Then it happens: The complaints and questions start to trickle in.
"Why can't we get information about X? Is it possible to get a report on Y? How can
I track A so that B is part of the equation?"
Your architecture is still just as great as it was the day it was rolled out, yet
your users are no longer happy. They've reached the point where the information
they have isn't enough for them. They have new questions, new requirements, new
problems that your configurations just don't meet. Perhaps the capabilities you initially gave
them allowed them to think beyond earlier plans, and those thoughts
are triggering new ideas for them. Perhaps they're recognizing that information
they once needed is now obsolete. They need an application architecture that can
scale and adapt up, down, and around with them. To get that, they need an
application architect who can think ahead for them.
While some problems may never be completely solved -- after all, technology
sometimes just doesn't keep up as quickly as needed -- using scalable and adaptive
thinking during the application architecture planning process can help you
anticipate the types of problems and questions that might arise long after
implementation.
Scalable thinking at a glance
As you consider the scalability of the applications in your design, take a
step back. You've asked for business requirements to get to this point, but
were you clear with the business team on the time frame of those requirements? For
example, did you ask for today's business requirements? Or did you
ask the team to think ahead and anticipate what their needs might be in
three or five years? Keep in mind that when the business teams hear from
architects, they have no clue what you actually do. They won't realize
that you're attempting to make their world a better place; they often look at
the requirements-gathering process as a pain-in-the-neck task on a long list of
items to do. Asking them to think ahead can help them understand your role and
how it fits into their world.
One way you can help the business team help you is to ask users for a "wish
list" -- information that they would ideally like to have, regardless of
current requirements. This approach accomplishes two things: First, it gives
your users more incentive to participate accurately in the requirements-gathering
process, and second, it gives you an understanding of what your users really
want. Perhaps you can't give them everything now for budget or other reasons,
but if you know today that your users really want the ability to instantly
view shipping costs from four different carriers at once, then you have a
requirement you can work toward in the future. There are no surprises, because
you already know that that's what your users want. And by communicating clearly
to users, they will know that you intend to provide that feature eventually
through an incremental upgrade, for example.
Scalable thinking cannot be an afterthought. Applications and resources must be
designed to handle diverse changes in user needs, business strategies, and
competitive pressures. The trick for an application architect, then, is to
understand where the actual scalability is needed. The only way to do that is
to involve users in the architecture process by asking them to think on a
scalable level, too.
Adaptive thinking in the real world
Human thought takes place on many levels, some of which are rational and some of
which are not. Gerd Gigerenzer, author of Adaptive Thinking: Rationality in
the Real World, says that adaptive thinking is the way the mind copes with
an environment, both ecological and social. In times of stress or overload,
the mind copes by closing itself off to new ideas and instead, focuses on simply
getting the job at hand done. But in the world of technology, adaptive thinking can be
expanded into the idea of using existing knowledge to create innovation. This
kind of thinking can keep the mind open instead of closed when technological
stresses occur.
If you keep in mind the concept that all things are connected and all progress
comes from what you already know, then you can become inspired to find new
ways to handle application architecture environment issues. For example,
many organizations suffer greatly from the status quo -- they are so mired in
the tasks of their daily existence that they simply cannot focus on the future. They see
problems all around, and innovation is simply a word tossed about
during business meetings. But what if you took the existing knowledge you had
about how your organization works and saw opportunity -- instead of problems --
everywhere? You could then adapt your thinking to the opportunities that exist
rather than the current business requirements that drive your organization.
Adaptive thinking can also help you identify more closely with the business
teams you work with. Often, the business environments your work supports and
enables are bombarded with continual pressures that limit creativity and force
people to solve daily dilemmas. It's the classic reaction to stress: Get the
job done, you don't have time to think about what will make the job easier. As
an outsider, you can step into that business situation and use adaptive thinking
to truly add value to these teams. As your designs unfold, your foresight and
creativity will begin to show how application architecture can improve the
overall organization. At that point, the business teams will begin to appreciate
the true magnitude of what you do.
Tools and techniques: Simplify and
integrate
Simplify, simplify, simplify. We've all heard that, but how often do you really
apply it to your designs? When you include growth as a key element in a design,
simplicity is critical. The more complicated your design, the more difficult it
will be to integrate other applications or processes into it in the future. An
earlier article
in this series discussed the required skill of seeing the forest and the
trees, not just one or the other. That skill translates into a technique for
growth. The more you can see the large-scale and small-scale aspects and
implications of what you're doing, the easier it will be to see where you can
include long-term growth in your design -- and where you can't. Apply what you've
learned through adaptive thinking with your business teams, and then compare that
long-term information to the design. How simple will it be to make necessary
changes down the road? Keep working at the design until you reach a point at which
you can no longer simplify any aspects of it.
As you simplify, identify all the points at which integration can occur. Look at
this from the current environment perspective, of course, but also from the future
perspective. Are you including an application that you probably won't be able to
integrate with anything beyond its current capabilities? While you may include that
software because it's the most robust solution today, you may want to reconsider
the solution if it means purchasing and deploying a new solution in a year because
of growth demands. Your business teams may agree to a different solution now if
it means giving them desired capabilities in the future.
Tools and techniques: Reliability,
performance, and availability
Any savvy application architect reviews applications and overall design with the
concepts of reliability, performance, and availability in mind. Of course,
everything has to work, has to perform to standards, and must be available upon
demand. It it isn't, your design is neither reliable nor effective. However, as
you review your design, use adaptive thinking to plan for growth. What happens if
changes that users want in the future are made with this design? How will that
affect reliability and other factors?
It's almost as if you need to create two designs: a working design and a future
design. Every time you change the working design, compare that change to the
future design. How will the legacy system you're maintaining now integrate with
currently emerging technologies -- for example, with Extensible Markup Language
(XML) or Asynchronous JavaScript + XML (Ajax) -- that appear to be making
fast progress on the business front? How well do current systems and tools
integrate with your current design when you consider future growth? Could your
organization invest in other applications now to make long-term growth more
manageable? By considering these items now, you will make it easier to cope with
change and growth over time.
Tools and techniques: Building
blocks
Using a set of applications as building blocks is a flexible method used in
application architecture to help streamline and integrate core business processes.
Building blocks can reduce interface complexities as well as increase production
across multi-delivery channels. They can also reduce the maintenance costs of
multiple systems by reducing the overall time and effort required to monitor and
upgrade individual systems. At the same time, you can easily expand capabilities
and track them with more accuracy: There aren't as many applications to supervise,
and capabilities are available across the organization.
By using core applications and building upon them as your organization grows, you
can:
- Define the gap between your current and planned information technology (IT)
environments.
- Build operational models to transition to new application environments that
can scale to support corporate growth.
- Share information across departments (and enhance collaboration at the same
time).
- Lay the foundation for future growth.
IBM used a building block approach with Hyundai Marine & Fire Insurance Co. of
Seoul. Using IBM Insurance Application Architecture as the starting point, Hyundai
created a system that offered great flexibility. The initial applications chosen
for the solution were used as building blocks for both planned and unplanned
changes in growth -- each application was chosen for its ability to easily
integrate and support other applications over time. The company says that it
achieved many benefits by using the building-block approach, including the
ability to predict price wars and ease administrative demands as new pieces of
the building-block strategy were deployed. The building-block approach helped
minimize business risks, improve reliability, and reduce implementation costs.
It's a valid approach, but one that may require educating your business teams on
your strategy for growth before building blocks can be used. In some organizations,
business units are so dependent upon niche applications that it could take some
time to convince them that a building-block approach will not only help them but
the entire organization, as well. If you run into resistance at lower levels, try
educating upper-level executives on the building-block approach instead. It might
take their acceptance and endorsement before individual business units can be sold
on the concept.
Milestones
I've talked a lot about working with business teams when designing for growth. These
teams are, in many ways, your customers. Combine that with external customers such
as consumers, business partners, vendors, and suppliers, and you have quite a large
audience to design for. The following milestones can help you cover all the needs
of these diverse audiences.
Integration strategy
An integration strategy is different from designing how actual applications will
be integrated. This milestone is more about defining and communicating your
strategy to the proper audiences to gain buy-in for your plans. After you have
worked with your business teams and determined where you can simplify and
integrate, it's time to write a brief document outlining the strategic approach
you're recommending. It should be simple, written in "lay" terms (terms anyone
can understand), and it should include some simple graphics that show readers
how the strategy works and what you expect its results to be.
I can't stress enough that this strategy should be brief and simple. Think in
terms of an "elevator pitch," which is how public relations teams describe the
messages they want to get across quickly to people who might not be well versed
in a given topic. If you can't explain your strategy clearly in the time it
takes for an elevator to rise 10 stories, you haven't simplified it enough for
your business units. You're the expert on the applications and how they should
be integrated; no one will dispute that. Your integration strategy should be
written to help everyone else in the organization fully understand what you're
doing -- to the level they can understand it. If you're not sure whether someone
else can easily grasp the information you're sharing, ask someone outside of
IT to review it and provide input.
When you have written the strategy, make it widely available to anyone who wants
it. Distribute it to executives, managers, and other decision makers who will be
providing you with the budget to make your strategy happen. When everyone
understands your strategy -- and your plan for handling growth -- you'll find it
easier to get things done and maintain support for your ongoing requests related
to the strategy.
Roadmap
Planning for growth doesn't always mean that you can have everything you want.
Sometimes, the money just isn't there. In other cases, the flexibility of the
system just won't support your plans. Perhaps certain events will block you from
deploying a particular application at a particular time. Or perhaps a certain
department needs specific capabilities by a certain date. Whatever the issues,
you need a roadmap to help you identify obstacles, timing options, and other
issues that can affect plans for growth.
In "Using a
phased methodology in business process management," I showed how a simple
roadmap can work. By highlighting key activities and events, you can visualize
time frames clearly -- and help others visualize them, too. I highly recommend
including a roadmap in your strategy document to help clarify the points you
make about long-term strategy and growth.
Service level agreements
There is one other item to consider when planning for growth: service level
agreements (SLAs). Do you know how many your company has and which applications
they're tied to? If you don't, you must find out as quickly as possible.
Corporations can spend hundreds of thousands of dollars on SLAs, and the costs
involved can stop you in your tracks as you plan for growth.
If your company, for example, has an annual service agreement for a particular
application that you want to phase out, find out when the agreement expires as
well as when it is renewed. These are often two different dates. If your
company has already renewed an agreement for the following fiscal year, your
strategies for growth might have to wait until that agreement expires. In
addition, your new architecture must be fully operational before that agreement
expires to avoid problems for business units. Knowing what these agreements
affect and the timing of each will help you effectively plan for growth.
Summary
Planning for growth in your application architecture does require placing yourself
in your customers' shoes. What do they need? What do they wish they had? When can
that happen for them? But by focusing on customer-centric business strategies
through the use of scalable and adaptive thinking, you can effectively set
strategies in place that keep your customers happy now -- and in the future.
Resources Learn
Get products and technologies
Discuss
About the author | 
| | S. E. Slack is a Studio B 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
Company. 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 five other books. |
Rate this page
| |
