Justified and optimized

In last month’s issue, Jim Quiggle discussed service-oriented architectures
and infrastructures (SOA/I), which represent a shift in the way IT departments
operate. As this trend grows, it is even
more important that IT departments are
optimized and justified.

“Architectures and infrastructures that
don’t support the business have no justification to exist,” says Quiggle, director of
professional services development at
Agile360 Inc. “If they are not optimized,
they don’t enable business agility and may
hinder workflows. SOA/I coupled with
operational and solution frameworks can
close the gap between the business drivers
and deployed IT service solutions. These
are justified by business need and optimized based on the costs versus the business benefit provided or business risk
avoided or mitigated.”

Smart Business talked with Quiggle for
more insight into methods for justifying
and optimizing infrastructures and architectures.

How is justification and optimization affected
by SOA/I?

The traditional approach is based on
‘pain points.’ One example is when someone complains about the speed or features of the e-mail system. Another example is when business management
expresses a need for a way to manage
warehouse inventories, and a solution is
implemented.

When pain points drive IT solutions, the
deployed systems probably are over-engineered, and therefore, cannot be optimized. This is because the chances of hitting the unknown service level requirement mark is low. If the systems are
under-engineered, IT must deploy additional systems to resolve the continuing
pain points.

With SOA/I, the pressure is taken off IT,
and the rest of the business defines what
is needed. IT then presents the available
options and trade-offs for business
approval. Justification is based on the needs of the business as determined by
the various entities within the business.
There is also the potential benefit of meeting the needs of partners that deal with
the business with no additional cost for
processes.

How does a business go about implementing
SOA/I?

You start with the business objectives.
Vision and strategy come next. It is important to involve all departments of the business. You want to build support services
and applications so that the different business systems can reuse and share them.
The architecture is leveraged across multiple projects — both internally and externally — eliminating the need to rebuild
similar services for each project.

After an organization has set its SOA/I
vision and strategy, then the architecture
and every infrastructure component
across the whole enterprise conforms to
the SOA/I. Services become the basic
building blocks with which infrastructure
architectures are created and supported.
These services are integrated to achieve
business objectives.

Are there standards or frameworks to follow?

There are two, and they are very similar.
One is the Information Technology Infrastructure Library (ITIL). The other is the
Microsoft Operations and Microsoft
Solutions Frameworks (MOF/MSF). They
are very similar.

MOF adopts and adapts ITIL and combines the collaborative industry best practices with specific guidelines for running
on the Microsoft platform in a variety of
business scenarios. MOF also extends the
ITIL code of practice to support distributed
IT environments and current industry
directions such as application hosting,
mobile-device computing, and Web-based
transactional and e-commerce systems. In
a non-Microsoft environment, the ITIL
framework would simply replace the MOF
and MSF frameworks.

Are there basic steps to follow?

There are four basic steps to create a new
solution (or change an existing one). They
are: (1) plan the solution, (2) build it, (3)
deploy it and (4) operate it.

This approach recognizes that a change
to a current solution can originate from an
operations requirement, a new business requirement or external factors, such as regulatory requirements. These changes also
need to follow the four basic steps of the
life cycle and, depending on their complexity, can trigger either a new (MSF) project
or a smaller-scale request for change within the MOF framework.

Each framework provides useful and
detailed information on the people, processes and tools required to successfully
function within its respective area. Both
MSF and MOF provide technology-agnostic guidance for improving IT processes
that can be used in any environment.

JIM QUIGGLE is director of professional services development
at Agile360 Inc. Reach him at [email protected] or (949) 253-4106.