Using a Service

Oriented Architecture

to Manage IT Sprawl

Jeffrey Hurley

Background Photo: Hojusaram. "20070311-130204.jpg." Flickr. Yahoo!, 11 Mar. 2011. Web. 10 Feb. 2015.

Understanding Sprawl• Evolving Technology Systems Sprawl

• Layered systems (custom applications, mainframes, client server, enterprise

resource planning, clouds, mobile devices, web applications)

• Cobbled solutions (point solutions over enterprise solutions)

• Inaccessible silos (multiple databases with same data maintained by different

groups)

• Systems snarled in spaghetti (point solutions and quick fixes)

• Changing Business Organizational Sprawl

• Geographic expansion

• Mergers and acquisitions

• Consolidation

• Outsourcing

Your Legacy is Drowning

You• Making a change to the technology environment can be difficult and

risky with multiple layers of system dependencies

• Environmental complexity creates a situation where an individual

cannot understand all of the systems

• Maintaining these systems becomes increasingly expensive year-

over-year

• Corporate systems do not “talk” to each other (by design or

oversight)

• Multiple programming languages, architectures, and processing

(R/T, Batch, Sneaker Net)

• System and business “silos” create pockets of duplicate or similar

data (customer, financial, product, etc. databases)

IT Organizational Sprawl

• Fragmented by technology platform (split along vendor package or

platform)

• Fragmented by function (specialized groups: design, development,

testing, deploying, support, infrastructure, architecture, etc.)

• Fragmented by geographical location (outsourced, near sourced,

acquired, international expansion, etc.)

• Fragmented by corporate entity or subsidiary

• Fragmented by in-sourced vs. out-sourced teams

• Fragmented by business unit

• Fragmented by business focused team vs shared “IT services”

Translate Into Organizational

Challenges• Political infighting

• Power struggles

• Obfuscation

• Hostility

• Perception of repeated failed, delayed, and overly

complex projects

Why the Focus on

Problems• Service Oriented Architecture looks to fix these

problems

• At the same time these problems are the biggest

challenge to adoption of a Service Oriented

Architecture

• If you don’t understand what you have it will be

much harder to fix it.

A Service Oriented

Architecture Can

• Expose pre-existing functions trapped deep in

systems and services.

• Create interoperability agreements for system

reconciliation between departments and “technology

silos”

First, Establish Design

Policies• Interoperability

• Discoverability

• Security

• Uniqueness

• Interface compliance

• Data format compliance

• Metrics

Set up Run-time Policies• Service-level agreements: most common IT refrain. An agreement

between the providers and consumers on expectations and performance.

• Authentication: This is how your technology environment allows access to systems most often referred to as a desire for “single sign-on”

• Authorization: Determining if a specific system or provider is able to invoke a service

• Encryption: This has become an increasingly hot topic in the age of security. Are we encrypting our systems, information, and data internally so that they are not read by the wrong people

• Signatures: I am referring to the technical signature between systems exchanging information, similar to when you sign for a package that confirms you received it.

• Alerts and notifications: Requiring systems to have alerts properly built in to notify the appropriate people and systems of current conditions.

• Metrics: What are the key performance indicators (KPIs) that will be measuring systems and influencing decision making

Leave-and-Layer SOA

Strategy• The services you need most are already in

existence in your current systems

• The current systems have already been tested for

consistency and reliability

• Building a service on top of an existing system is

faster and cheaper than creating a new service-

oriented system

• This will protect the dollars already invested in your

systems and technology

Use an Enterprise Service

Bus (ESB)• You will need a tool to handle your legacy systems

that you plan to build services on top of

• The tool should handle multiple protocols, message

formats, and provide adaptors

• Communication patterns: request/reply,

publish/subscribe, fire and forget, etc.

• Provide service mediation to provide security, quality

of service, encryption, authentication, authorization,

load balancing, and monitoring

Create Organizational

Agility• Establish a value chain mindset (it exists to deliver

customer satisfaction)

• Break application-centric thinking with cross product/project assessment

• Challenge the organization and the staff to deliver solutions via services and interoperability

• Establish stakeholders: business owners, architects, developers, quality management, operator/consumer

• Avoid creating services that require behavioral changes unless absolutely necessary

Funding Your SOA

Strategy• Use existing technologies and processes extending

the return on investment (ROI) and return on assets

(ROA) of existing systems

• Reuse will reduce costs across groups, seek to save

approximately 5% a year in support costs; using

these dollars to fund the SOA strategy

• Demonstrate faster time-to-live and as a result time-

to-market for new and existing systems utilizing the

SOA architecture

IT SOA Value Metrics

• Speed of deployment

• Number of reusable services

• Percentage of new services vs. existing (reused)

ones

• Percentage of reusable services vs non-reusable

services

• Number of applications bound to each service

• Lifetime cost of a service

Photo Credits

• Hojusaram. "20070311-130204.jpg." Flickr. Yahoo!,

11 Mar. 2011. Web. 10 Feb. 2015.

•