why we’re heredoveltech.com/wp-content/uploads/2017/09/practicalsoafor...– vendors (ibm, oracle,...

1

Copyright © 2007, ZapThink, LLC 1

SOA For Government:Welcome!

Ronald Schmelzer and David Linthicum


Why We’re Here

• Learn about Service-Oriented Architecture (SOA) and its relationship to Federal Enterprise Architecture (FEA)

• Learn how SOA is used in the Federal Government

• Learn from Peers about their SOA experiences• Learn from Vendors about their SOA

capabilities• Have some coffee• Meet some great people


Agenda

17:00-18:00Networking Reception and Sponsor Interaction

Jim Mackay, CMO, iTKO, Inc.15:30-16:15Testing and Trusting in Federated SOA Software Environments

Ronald Schmelzer, Senior Analyst, ZapThink

14:45-15:30The SOA Implementation Roadmap

14:30-14:45Coffee Break

Steven W. Hansen, Solution Architect, Nexaweb

13:45-14:30Solving the Last Mile of SOA with Enterprise Web 2.0

Ronald Schmelzer, Senior Analyst, ZapThink

13:00-13:45SOA Pilots & Government Case Studies

Jordan Haberfield, Excel Partner12:00-13:00Lunch Break & Special Sponsor Presentation

David Linthicum, Linthicum Group10:15-12:00Defining the Value of SOA for the Government

10:00-10:15Coffee Break

David Linthicum, Linthicum Group08:45-10:00Introduction to SOA for Government

David Linthicum, Linthicum Group & Ronald Schmelzer, ZapThink, LLC

08:30-08:45Session Start & Introduction

08:00-08:30Session Registration

DetailsTimeSession title

2


Sponsors


Thank You!

Photos © Lisa Polucci

Practical SOA for the Federal Government

David S. [email protected]

Agenda• Introduction to SOA for Government

– Current Architectures – Federal Enterprise Architecture (FEA) – Understanding the Objectives

• Defining the Value of SOA for the Government– Approaching SOA

• Semantics • Services • Processes • Design • Architecture • Technology Selection • Testing

INTRODUCTION TO SOA FOR GOVERNMENT

Copyright 2007 The Linthicum Group, LLC


Current Issues• Competing frameworks/approaches

– Zachman Framework– Gartner/Meta Group– Open Group’s TOGAF (SOA Reference Architecture)– Vendors (IBM, Oracle, BEA, etc.)– Roll-your-own

• Hype-driven confusion (e.g., “SOA 2.0”)• Lack of leadership• Processes moving outside of the firewall• Departments operating independent of oversight• More enterprise applications are Web-delivered• Technology as a business advantage and cost saving

mechanism


Understanding the Forces at Work

SOA

SaaS

Web 2.0

Emerging Standards

Hype

Enterprise Architecture

Cost Reduction


EA and SOA…Let’s Face Facts

• There seems to be two worlds out there, the world of enterprise architecture and the world of SOA. – “The funny thing is that those in each world thinks that

they can do the other world's jobs.”– “The end result...there is not a lot of synergy there

yet.”


More good news…Some traditional enterprise architects have not done a stellar job in understanding the opportunities within SOA, generally speaking, and the SOA guys have not figured out how SOA meshes with existing enterprise architecture standards, notions, and practices, again generally speaking.


Understanding the Pain Points“A recent survey by the Business Performance Management Institute found that:

• Only 11 percent of executives say they're able to keep up with business demand to change technology-enabled processes.

• 40 percent of which, according to the survey, are currently in need of IT attention.

• Worse, 36 percent report that their company's IT departments arehaving either "significant difficulties" (27 percent) or "can't keep up at all" (9 percent).”

– CIO Magazine


So, the EA “Mega Trends”1. SOA, SOA, SOA!2. SaaS3. “Web 2.0”4. “Enterprise 2.0”

– Mashups– Inside-out– Outside-in

5. Incorporating existing Enterprise Architecture concepts and practices…how?


State of ThingsThe survey was of 196 Information Technology

(IT) decision makers.

"Indicators point to the fact that IT professionals overwhelmingly support the SOA concept with 56 percent reporting they believe their company/agency would benefit from a SOA. Among those who have experienced a SOA implementation, 73 percent would recommend other companies/agencies follow suit and adopt a SOA approach. “


But, there is Reality

• Hype is huge, and management by magazine is the way of the world these days.– “I got to git me one of them SOAs”– “A SOA will fix that.”– “SOA 2.0”

• Bad practices:– Selecting technology before understanding your

requirements and needs.– Not linking back to accepted EA best practices.– Not creating a business case.– Using the wrong people.– Lacking funding and empowerment.


So, Why SOA?• Improved Adaptability and Agility

– Respond to business needs in near real-time• Functional Reusability

– Eliminate the need for large scale rip and replace• Independent Change Management

– Focus on configuration rather than programming• Interoperability instead of point-to-point integration

– Loosely-coupled framework, services in network• Orchestrate rather than integrate

– Configuration rather than development to deliver business needs


Data Abstraction

Data Data

Data Services/Messaging

LegacyLegacy LegacyLegacy

Services

Process/Orchestration

Monitoring/Event Management

Governance

Rep

Security

Internet-Based

ServicesNew Services

SOA Meta Model

SOA and the FEA

• Key things to remember:– FEA is intentionally vague.

• Focus on the notion of standards, but not particular standards.

• Focus on high-level concepts, not specific technology.

– Focus on sharing models, data, and core architectures among agencies.

– SOA is a component, not holistic to the FEA.


15

SOA and the FEA

FEAFEA

Data ReferenceModel

Data ReferenceModel

BusinessReference Model


Service ComponentReference Model


Technical Reference Model


PerformanceReference Model


Note: While there are some SOA concepts within the PerformanceReference Model and the Business Reference Model, the primary use ofSOA is within the other models.

16

Service Component Reference Model (SRM)

FEAFEA

Data ReferenceModel

Data ReferenceModel









Service Component Reference Model (SRM)

• The SRM is a business and performance-driven, functional framework that classifies Service Components with respect to howthey support business and/or performance objectives.

• The SRM is structured around Service Domains, Types, and Components.

• The SRM Service Domains provide a high-level view of the services and capabilities that support enterprise and organizational processes and applications. They are differentiated by their business-oriented capability, and include:

– Customer Services– Process Automation– Business Management Services– Digital Asset Services– Business Analytical Services– Back Office Services– Support Services

17

SOA and the SRM• Customer Services - Access to critical services

supporting user interactions, and the loose coupling of the data from the applications/service.

• Process Automation - Access to services in support of BPM, and the loose coupling of the data from the applications/services.

• Business Management Services - Access to views of data and information, and the loose coupling of the data from the applications/services.

18

SOA and the SRM• Business Analytical Services – Access to key data stores

supporting abstracted views for the delivery of business intelligence solutions (single model view of many data sources, links to business intelligence tools, calculated points, etc.).

19

Data Warehouses

RDBMS XML Docs Flat FilesPackaged Apps

Reporting

Data Services

20

Technical Reference Model (TRM)

FEAFEA

Data ReferenceModel

Data ReferenceModel









Technical Reference Model (TRM) Consists of:

• Service Areas, which represent a technical tier supporting the secure construction, exchange, and delivery of Service Components.

• Each Service Area aggregates the standards and technologies into lower-level functional areas.

• Each Service Area consists of multiple Service Categories and Service Standards.

• This hierarchy provides the framework to group standards and technologies that directly support the Service Area.

– Including:• Service Access and Delivery• Service Platform and Infrastructure• Component Framework• Service Interface and Integration

21

TRM Service Areas and SOA• Service Access and Delivery

– Provide services interfaces for key applications.– Leverage services, using a logical business-oriented model for access.– Loosely couple data from services.

• Service Platform and Infrastructure– Access to data using a logical architecture spanning the organizations.

• Component Framework– Provide a catalog of services for data interaction.– Leverage databases through a loosely coupled mechanism.

• Service Interface and Integration– Integration– Interface– Interoperability

22

TRM and the Component Framework

• Consists of the design of application or system software that incorporates interfaces for interacting with other programs and for future flexibility and expandability, including:– Business Logic– Data Interchange– Data Management– Presentation/Interface– Security

23

TRM, the Component Framework, and SOA

• Business Logic – Service access to control and reference logic controlling access to data.

• Data Interchange – Abstraction of disparate data sources into a single loosely coupled data services layer.

• Data Management - Abstraction of disparate data sources into a single loosely coupled data services layer.

• Presentation/Interface – The aggregation of data using services to create common views for interfaces.

• Security – Controlling access to data using services and Web services security standards, such as WS-Security.

24

25

Data Reference Model (DRM)

FEAFEA

Data ReferenceModel

Data ReferenceModel









Data Reference Model (DRM)

• The DRM provides a standard means by which data may be described, categorized, and shared. These are reflected within each of the DRM’s three standardization areas. – Data Description– Data Context– Data Sharing

26

The DRM and SOA• Data Description – By leveraging a services layer the

organization is able to describe data in any way that fits the use case. This is possible since the logical access layer is decoupled from the physical databases.

• Data Context - Leveraging data services to support taxonomies, ontologies, and common database definitions.

• Data Sharing – Using data services to leverage common custom views of the data to meet any purpose, technology platform, and information format.

27

DEFINING THE VALUE FOR THE GOVERNMENT


JBOWS vs. SOA

• JBOWS = Just a Bunch of Web Services.

• SOA = Use of services to form solutions quickly and easily.



The Value Proposition of a SOA

• We implement SOA for two major reasons. – First is the ability to save development dollars

through reuse of services.– Second is the ability to change the IT

infrastructure faster to adapt to changing needs of the business, or agility.

– Enhance, not replace, existing EA.


Reuse…Yes Again• Under the concept of service reuse, we have a

few things we need to determine to better define the value. These include:– The number of services that are reusable.

Complexity of the services. The degree of reuse from system to system.

• The number of reusable services is the actual number of new services created, or, existing services abstracted, that are potentially reusable from system to system.

• The complexity of the services is the number of functions or object points that make up the service.

• Finally, the degree of reuse from system to system is the number of times you actually reuse the services. We look at this number as a percentage.


So, What do you Do?• In order to determine their value we must first determine

the Number of Services that are available for Reuse (NSR), the Degree of Reuse (DR) from system to system, as well as the Complexity (C) of each service.

• The formula to determine value looks much like this:

Value = (NSR*DR) * C


SOA=Agility• Agility is a strategic advantage that is difficult to

measure in hard dollars, but not impossible. We first need to determine a few things about the business, including:

• The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market.

• The ability to adapt to change is a number that states the company’s ability to react to the need for change over time.

• Finally, the relative value of change is the amount of money made as a direct result of changing the business.

34

Understanding the SOA Levels…What Works for Your Enterprise?

• Level 0 SOAs are SOAs that simply send SOAP messages from system to system. There is little notion of true services, but instead, they leverage Web services as an information integration mechanism. Hardly SOA, but certainly a first step.

• Level 1 SOAs are SOAs that also leverage everything in Level 0 but add the notion of a messaging/queuing system. Most ESBs are level 1 SOAs, leveraging a messaging environment that uses service interfaces, but really does not deal with true services (behavior), and instead moves information between entities as messages through queues.

• Level 2 SOAs are SOAs that leverage everything in Level 1, and add the element of transformation and routing. This means that the SOA can move information from source and target systems, leveraging service interfaces, as well as transform the data/schemas to account for the differences in application semantics. Moreover, by adding the element of intelligent routing, you're able to route the information based on elements such as source, content, and logical operators in the SOA.

• Level 3 SOAs are SOAs that leverage everything in Level 2, adding a common directory service. The directory provides a point of discovery of processes, services, schemas, and such, allowing all those who leverage the SOA to easily locate and leverage assets such as services. Without directories, the notion of service reuse--the real reason for building SOAs--won?t work. Directories are typically standards-based, including UDDI, LDAP, and sometimes more proprietary directories such as Active Directory.

• Level 4 SOAs are SOAs that leverage everything in Level 3, adding the notion of brokering and managing true services. Here is where the brokering of application behavior comes into play. In other words, at this level we are not only about managing information movement, but the discovery and leveraging of true services.

• Finally, Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration.Orchestration is key, providing the architect with the ability to leverage exposed services and information flows, creating, in essence, a "meta-application" above the existing processes and services to solve business problems.


How Do you Build A SOA?

Understand your business objectives and define success.

Define your problem domain.

Understand all applicationsemantics.

Understand all services.

Understand all processes.

Define new services.

Define new processes.

Select your technology set.

Deploy SOA technology.

Test and evaluate SOA solution.


Understand your business objectives and define success.

ROIROIDefine ROI

Create Business Case

BusinessCase

BusinessCase


Define your problem domain

SystemDescriptions

SystemDescriptions

System Complexity Analysis

SOA POC

POCResults

POCResults

DomainDescriptions

DomainDescriptions

Vendors


Understand all applicationsemantics in your domain.

SOAMetadata

SOAMetadata

Meta data analysis

Data abstraction layer definition

DataAbstraction

Layer

DataAbstraction

Layer

Data services definition

DataServices

DataServices

LegacyMetadata

LegacyMetadata

ExternalMetadata

(B2B)

ExternalMetadata

(B2B)

39

Data abstraction and the Database

Customers

Orders

Invoices

Trades

Positions

Vendors

Employees

POs

GLs

Data Warehouses


ExistingData

DataServices

Layer

BusinessApplications

ReportingDashboards Composite Apps

Customers

Orders

Invoices

Trades

Positions

Vendors

Employees

POs

GLsCustomers

Orders

Invoices

Trades

Positions

Vendors

Employees

POs

GLs

Data Warehouses


Data Warehouses

Data Warehouses

RDBMSRDBMS XML DocsXML Docs Flat FilesFlat FilesPackaged Apps

Packaged Apps

ExistingData

DataServices

Layer





Data Services and ROI

• The value proposition of data services is the ability to loosely couple both services and applications from the underlying physical database.

• This provides the value concept of agility, or the ability to change the database without effecting processes, services, and applications.

40

Customers

Orders

Invoices

Trades

Positions

Vendors

Employees

POs

GLs

Data Warehouses


ExistingData

DataServices

Layer



Customers

Orders

Invoices

Trades

Positions

Vendors

Employees

POs

GLsCustomers

Orders

Invoices

Trades

Positions

Vendors

Employees

POs

GLs

Data Warehouses


Data Warehouses

Data Warehouses

RDBMSRDBMS XML DocsXML Docs Flat FilesFlat FilesPackaged Apps

Packaged Apps

ExistingData

DataServices

Layer





Data Services and ROI

• When measuring agility we first need to determine a few things about the organizational requirements, including:– The degree of change over time or the number of

times over a particular period that the an organization changes itself to adapt to a new mission or missions.

– The ability to adapt to change is the organization’s ability to react to the need for change over time.

– Finally, the relative value of change or the amount of money made or saved, as a direct result of the changes.

41

Data Services and ROI – The Calculation

• Considering an average value of agility, the value of data services is directly related to the number attributes contained within any number of disparate data sources, multiplied by the complexity of the data.

• For instance, if you have 5 data sources, with an average of 800attributes (e.g., columns), with a medium level of complexity (1% to 100%, thus 50%) the formula would look like this:

Relative Value of Data Services (loose coupling of data) =(# of Data Sources * # of Attributes) * (complexity ranking)

Or, for our example:ROI = (5 * 800) * (.5) or a ROI ranking of 2,000

42

Data Services and ROI – The Calculation

• Best practices demonstrate that an ROI ranking point equals to about $1,000 USD (value), or:

• ($1,000 * 2,000) or $2,000,000 potential savings over a 5 year span of time when using a data services layer, versus not using a data services layer.

• This number could be adjusted up, if the relative value of agility is higher, or lower if the relative value of agility is lower.

43


Understand all servicesin your domain.

CandidateServices

CandidateServices

Service analysis

Metadata andservices analysis

ServicesAnd

Information

ServicesAnd

Information

Performance analysis

ServicesAnd

Performance

ServicesAnd

Performance

LegacyServices

LegacyServices

ExternalServices

(B2B)

ExternalServices

(B2B)

SOAMetadata

SOAMetadata


Understand all processesin your domain.

CandidateProcesses

CandidateProcesses

Process analysis.

Define metadata, services,and processes

Processes,Services,

AndInformation

Processes,Services,

AndInformation

Process integrationanalysis.

ProcessIntegrationDiagrams


CandidateServices

CandidateServices

ExternalProcesses

(B2B)

ExternalProcesses

(B2B)

SOAMetadata

SOAMetadata


Orchestration/Process

• Utilization of existing systems

• Live sharing of data and functionality

• Reduction of – Redundancy– Complexity– Maintenance costs– Project risks

• Increase of agilitySOA provides

functional infrastructure

App

App

App

App

AppApp

App

BP

MS

Workbasket

Source: www.enterprise-soa.com


Define new services.

CandidateProcesses

CandidateProcesses

Service definition.

Service design.

Processes,Services,

AndInformation

Processes,Services,

AndInformation

Service implementation.Process

IntegrationDiagrams


SOAMetadata

SOAMetadata

CandidateServices

CandidateServices

ServiceDefinition

ServiceDefinition

ServiceDesign

ServiceDesign

ServiceImplementation

ServiceImplementation


Define new processes.

CandidateProcesses

CandidateProcesses

Process definition.

Process design.

Processes,Services,

AndInformation

Processes,Services,

AndInformation

Process implementation.Process

IntegrationDiagrams


MetadataMetadata

CandidateServices

CandidateServices

ProcessDefinition

ProcessDefinition

ProcessDesign

ProcessDesign

ProcessImplementation

ProcessImplementation


Select your technology set.

TechnologyRequirements

TechnologyRequirements

Define requirements.

Technology analysis.

Technologysolution

Technologysolution

Vendors

Define candidate technology.

Technology selection.

Technology validation.


The Realities– Standards

• Too many to track• WS-*

– Technology• Service management• Governance• Data abstraction and the Database• Orchestration/Process• Emerging Stuff


Service management

• Tracking services through design, development, deployment, and testing.

• Core components:– Repository– Service control– Links to security– Designer


Governance

• Manage access and policy at the services level.

• Core components:– Directory– Repository– Policy management engine– Links to security– Service maturation


Emerging Stuff

• More focus on design and architecture• More use of external services (next

section)• More use of governance• Orchestration finally works• The Joining of SOA and Mashups• “Services for rent”



Fast Growing Web Services Market• “IDC estimates that $2.3 billion was spent worldwide on total Web services software

in 2004, more than double the amount from the previous year. IDC expects spending to continue to increase dramatically over the next 5 years, reaching approximately $14.9 billion by 2009.”

– IDC

• “According to Evans Data Corp's latest Web Services Development Survey, this year the percentage of functioning Service-Oriented Architectures (SOAs) has almost doubled.”

– Evans Data Corp.•

“Mash-ups portend big changes for software companies, Web sites, and everyone online. No longer just a collection of pages, the Web is morphing into a sort of global operating system …”

– Business Week

• “Why reinvent the wheel by having your staff spend time building service components, when you can quickly subscribe to a component, that's been tested and uptime certified, and pay for it on as-used basis?”

– Joe McKendrick, WebServices.org


Moving to “Outside In”• Today, more services exist outside the enterprise for use

within the enterprise.– Examples:

• Amazon.com • eBay• Salesforce.com• NetSuite• Many others

• Leveraging outside services provides enterprises with:– More agility with their ability to add, change, and delete

services as needed– Reuse of services they did not need to create or maintain– Better value chain integration incorporating both customers

and suppliers– Exposing business services outside of the enterprise “Inside

out”


However, it will Take Some Work• In order to make this a reality, we

must learn to how to bridge the gaps between our enterprise systems and SOAs, and Web service providers that exist across the Internet.

• Special consideration must be given to connectivity, interoperability, security, and shared processes.

• Problems are easily solvable with the right technology and approaches, but I would say that most out there looking at this new opportunity don’t have a clue as to how to make the new and old work and play well together.

• EA needs to lead the charge.


Understand Outside Interfaces

New Accounts

Finance/ Operations

CommissionCalculation

Sales

DataCleaning

On DemandApplications and Service Markets

Best Practices asShared Processes

Sales Order Update

SOA


Beyond SOA…SaaS, Web 2.0, Mashups, Oh My!

• We are moving toward a day when many of our enterprise applications may be delivered as services, and thus provide a more economical way to approach information technology management with businesses going forward.

• This is also the great equalizer since businesses, large and small, will have access to the same number and quality of services, much like they do with Web sites today.

• Shared services will create many opportunities, including better agility and the ability to operate a business with fewer IT resources.

• In essence, we're moving to Web 2.0 where service delivery over the Internet will be added to information deliver as the key strategic value of the Web to businesses, as well as extending the Web as a true platform.


Understanding the Problem• Service providers must integrate with existing

enterprise systems to become more valuable.• However, existing internal integration needs to

exist to ensure:– Production and consumption of structured information– Semantic mediation– Security mediation– Service enablement– Firewall management– Transactional integrity– Holistic management of complete integration chain


Getting Ready• So, how do you prepare yourself? I have a few

suggestions:– First, accept the notion that it's okay to leverage services

that are hosted on the Internet as part of your SOA. Normal security management needs to apply, of course.

– Second, create a strategy for the consumption and management of outside-in services, including how you'll deal with semantic management, security, transactions, etc.

– Finally, create a proof of concept now. This does a few things including getting you through the initial learning process and providing proof points as to the feasibility of leveraging outside-in services.


Remember, there are a few technical issues that you must address…

• Semantic and metadata management, or, the management of the different information representations amount the external services and internal systems.

• Transformation and routing, or, accounting for those data differences during run time.

• Governance across all systems, meaning, not giving up the notion of security and control when extending your SOA to the global SOA.

• Discovery and service management, meaning, how to find and leverage services inside or outside of your enterprise, and how to keep track of those services through their maturation.

• Information consumption, processing, and delivery, or, how to effectively move information to and from all interested systems.

• Connectivity and adapter management, or, how to externalize and internalize information and services from very old and proprietary systems.

• Process orchestration and service, and process abstraction, or, the ability to abstract the services and information flows into bound processes, thus creating a solution


Understanding the Change• It doesn’t take a rocket scientist to figure out that the creation of an

SOA on top of these applications, including process/orchestration layers, directory services layers, identity management, monitoring, semantic management, etc., would add a tremendous amount of value, considering the use of those applications and abstraction into real business solutions.

• Indeed, you’ll find that many SOA's for many businesses actually exist outside of their firewalls, making their on-demand applications work well together.

• This trend is only accelerating as “Web 2.0” becomes more valuable for enterprises.


Thanks!

• Blogs:– eBizq.net “Linthicum Channel”– InfoWorld “Real World SOA”– Intelligent Enterprise “SaaS Advisor”

• Weekly Podcast– InfoWorld SOA Report

• Columns– SOA World

1


SOA for Government:Case Studies

Ronald SchmelzerSenior AnalystZapThink, LLC


The Role of IT

• Is IT about getting the technology to work together or to help the business meet its goals?

• Does IT speak the language of business?

• Does business management see IT as an enabler or as a cost center?

WhoWho’’s in control of IT, anyway?s in control of IT, anyway?


The Integration “Rat’s Nest”

FBT PAY GNTS

TRDS

Client

Customs

RREIPS Integrated A/C Refunds

RBADef

PaymentsExcise

CR

PKI

ECI ADD AWA ELS

Client Staff RemoteStaff

TAXAGENTS

GCI

Call Centers

WOC

CCD

TASS

StaffPhone

ComplianceStaff

BOA

Ref material

Bus. Intel

NTS A/c

BEP

CDCCCWMS

BANK

DDDR

1

Data…….

Penalty

Business

IVR

1

2


We’ve had IT challenges for years …


… but even after yesterday’s promises…


… we still have the same IT mess, only worse.

3


SOA shifts the way we think

Architecture makes it workMiddleware makes it work

Leverage Heterogeneous Technology

Favor Homogeneous Technology

Compose ServicesIntegrate Silos

Loosely Coupled, Agile and Adaptive

Tightly Coupled

Designed to changeDesigned to last

Interactive and iterative development

Long development cycle

Metadata OrientedCode Oriented

Service Oriented ApproachTraditional Distributed Approach


Service Orientation:A Business Approach

• It’s not about connecting things, it’s about enabling business processes & continual change

• The core business motivation is business agility

• Rather than “rip and replace”old systems – make them work better together

• It’s not about technology, integration, or middleware


Architecture is not About the Technology

Just as a building architect is more concerned with the space, not the walls, the IT architect is concerned with how people use the technology, not the technology itself

4


Business Process the Old Way…

• People plugged into rigid processes• Inflexible & brittle


Business Process the Service-Oriented Way…

• IT resources (among other resources) available to the business as needed

• Business users create composite applications by composing Services on the fly


US PTO: SOALessons Learned &

the need for Continuing Education

Originally Presented by:Bob Brown

US Patent & Trademark Office (USPTO)S/W Development Organization (SDMG)At 2nd SOA for e-Gov (30 October 2006)

5


Positives at the USPTO

• Great infrastructure• Excellent staff• Agreement on standards SOAP, WSDL, XML• It appears that the USPTO are moving as quickly as

others in adopting the SOA approach• Strong showing with International Partners

– European Patent Office (EPO)– Japanese Patent Office (JPO)– World Intellectual Property Organization (WIPO)– International Bureau (IB) for Trademarks


Top Down, Bottom Up, Inside Out

• Regardless of how Services came into existence they have allowed us to– Decouple Systems

• Release impacts are minimized– Simplifying system release testing

• Less interface testing if services do not change

– Exposing only the information and environment necessary – e.g, no DB-links

– Allows simplified infrastructure changes• Server, Database, disk reallocations, etc.


SOA Working Group – Coming together to move forward

• SOA Working Group in existence for 2 years– Development Managers, Architects, Security Staff,

Testers, Standards people– Is mostly a technical focus– Contractors, Vendors, and Government

• Bring people up to speed and discuss shared concerns• Allowed cross-group insight into other’s efforts• Determine shared impediments• Vendor presentations on their support of SOA

– Current and planned

6


Successful Lessons Learned

• Communication and Education are excellent for a jump-start

• Have many areas involved in discussions—– Customers, Contractors, LCM Committee, Configuration

Management (CM), Operations Support• We set up the CM system to capture all Services as one

unit• We have addressed Fine-grain and Course-grain services• Behavior changes and testing

– For example, a regulation requires a behavior change• Thinking of “higher level” services

– Customer I/T Services could eventually span the USPTO


Less than Successful Lessons

• Difficult to go against Human Nature– Not invented here– Cannot meet my timeline, etc.

• Deciding the dividing line for the “Enterprise”– S/W + Infrastructure + Security + Extranet?

• The extra communication and responsibility required for sharing

• The loss of control• Changing the Game so shared services are in EVERYONE’s

interest– Changes to Performance Plans– Cash incentives– The anti-incentive job insecurity


Impediments to Rapid Migration

• Organizational– “Get_Customer” Service comes in many flavors at

the USPTO depending on context– moving to a basis for Enterprise services

• Power and Control– In the Government P&C = more people and more

$$s• Less code => less staff & funding

– No counteracting Stock Price• Ownership of Services

– Whom should create?– How is owner “compensated” for shared services?

7


Going Forward

• We have made it onto the Management’s radar• Attempting real Governance• Added processes specific to Services into the LCM• Addressing the issues of SLAs for Consumers of Services

– Response time, Availability, and Behavior• Factor in Consolidation with Services

– Removing functional replication even when handling different data, e.g. scanning


Conclusions

• The effort is accelerating• Many more people are aware and comfortable

with the concept• A big part of Services come in something called

COTS• As more-and-more Business Processes

standardize– Then Vendors can create services


Justice Reference Architecture

Service-Orientation for the State and Local Justice Community

Originally Presented by Christopher TraverBureau of Justice Assistance

At 2nd SOA for e-Gov Conference (10/30/2006)

8


Global’s SOA Initiative

• On Sept 29, 2004 Global adopted the recommendations found in the report: A Framework for Justice Information Sharing: Service Oriented Architecture (SOA)– Recognize SOA as the recommended framework for

development of justice information sharing systems

– Promote the utility of SOA for the justice community

– Urge members of the justice community to take corollary steps in the development of their own system


The Justice Reference Architecture…

An abstract framework for understanding the significant concepts and components of Service-Oriented implementations within the justice and public safety communities and for identifying where governance and technical standards are needed to support greater interoperability and information sharing.


JRA Desired Characteristics

• Reusability – Logic is divided into services with the intention of promoting reuse.

• Contracts – Services adhere to a communications agreement, as defined collectively by one or more service description documents.

• Loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.

• Abstraction – Beyond what is described in the service contract, services hide logic from the outside world and define explicit boundaries.

• Composability – Collections of services can be coordinated and assembled to form composite services which are inherently integrated without the need for additional layers of middleware.

• Autonomy – Services have control over the logic they encapsulate.

• Statelessness – Services minimize retaining information specific to an activity.

• Discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.

9


Barriers to Interoperability

• Common Vocabulary for Reference Architectures – OASIS SOA RM

• Information Model (i.e. GJXDM, NIEM)• Service Model• Services Definitions/Interfaces• Repository Issues• Service Interaction Requirements• Service Interaction Profile (Messaging)• Service Intermediary Issues• Policy/Agreements/Contracts• Governance• Execution Context (Implementation)


The Moving Parts


What Is Reusable Across Domains?

• Information Model– Core components like name and address

(GJXDM/NIEM)

• Service Interaction Requirements– Some requirements definitions

• Service Interaction Profiles (Messaging)– Some profiles (at least partially)– Some technical solutions—Web services, MQ,

wireless (maybe)

10


Lessons So Far…

• Justice is not alone – EA (FEA, NASCIO), CAP DE, HealthIT, PHIN, ISE

• Surprising amount of interest from our Federal partners – DOJ CIO, DHS, DNI, etc.

• The key to interoperability via SOA is loose coupling, but interface points require rigorously defined tech. standards

• Leverage industry partners with experience in this area – however NO ONE has attempted a reference architecture of this scope and diversity of potential participants

• Communicate the value of SOA in terms business people can understand – if a police chief can learn, anyone can!


Revisiting the Definition of Application

• Original definition of application was what task a computer was applied to– Colossus at England’s

Bletchley Park was applied to breaking codes, so that was its application

• The rise of programmable digital computers associated the word application with computer program


Web 2.0 vs. SOA

Web 2.0 SOA

Mashups

EnterpriseMashups

EnterpriseWeb 2.0

11


The Rise of the Mashup

• Mashup = a flexible composition of Services within a rich user interface environment

• In essence, a Mashup is a SOBA interface

Source: http://web2.wsj2.com


DIA and JackBe – Project Overwatch

• Problem– Laborious intelligence gathering

and sharing process, requiring use of multiple ‘stove-pipe’ all-source applications.

• Solution– Project ‘Overwatch’, Ajax-based

enterprise information portal, designed to empower end users to quickly paint a picture of situational awareness across various intelligence data sources, using a paradigm of drag-and-drop and bookmarking of the resulting briefing in a private workspace for future use and sharing.

• Benefits– Rapid solution development and

deployment, avoiding lengthy desktop certification processes.

“The use of Ajax for such a complex and critical application within the DIA is a big win for JackBe

and a strong endorsement of Ajax in general. It proves the enterprise-grade capabilities of both JackBe’s tools and consulting capabilities as the

company works to deliver similar rich, interactive front-ends to the data assets of other intelligence

agencies.”- Ron Schmelzer

Sr. Analyst & FounderZapThink


Challenge: Inertia in the Organization

• Architecture doesn’t have features and business executives pay for features!

• Moving to SOA means breaking down silos and sharing resources

• The technology change is easy – it’s the human change that’s the hard part!

12


Challenge: Balancing Control & Empowerment

• Answer: Governance• Establishing, communicating, and

enforcing policies, providing visibility into the levels of compliance, and dealing with issues

• Not just governance of SOA…governance with SOA

• But…avoid “big brother” effect

Who likes to be governed?Who likes to be governed?


Challenge: Reuse = Sharing

We all learned to share in kindergartenWe all learned to share in kindergarten……

But by the time we get to the working world, we But by the time we get to the working world, we forget how!forget how!


Challenge: People, Change and Fear

• People are inherently resistant to change

• People consider job security, authority and responsibility when asked to share

• Fear is the strongest emotion of all!

13


Silos Account for the $12 Million

Trans JrnlTrans WFlow

Discon.Opers

Training

Cust ID with PIN

DepositTrans

WithdrawTrans

TransferTrans

MultipleTrans/Cl

Stop Paymnt

CustomerSetup

AccountSetup

Account Inquiries

Night Deposits

Wire Transfer

SvngBndIssuance

Currency Orders

Comm.Deposits

MICRReaders

PINPads

MagneticReaders Printers

Cash Counting

Cash Dispens

CreditCrdAdvncs

Cash Mgmt

Reports/StatsWarnings

Ticklers

Branch Locators

Fee Collection

Fraud Verificatn

Check Ordering

Hold Paymnts

Check Batching

OLAP

MarketngPlanner

Lead Generat

Sales Lead

A/c CntctHist

Demographics

CampgnMgmt

Agent Status

Customer Profiling

Selling Prompts

Override Procssng

Operator Profiles

Task Mgmt

Cross Selling

CustPersonlz

Consolidated view

What-if Calculatr

Referral Procssng

Contact Tracking

ComplntReprting

ComplntTracking

Decision TrackingDesktop Functns

Safety Dep Box

StatemntPrinting

PaymentTrans

Trans Jrnl Discon.Opers

Cust ID with PIN

DepositTrans

WithdrawTrans

TransferTrans

MultipleTrans/Cl

Account Inquiries

Comm.Deposits

Printers

Cash Dispens

CreditCrdAdvncs

Fraud Verificatn

A/c CntctHist

CustPersonlz

StatemntPrinting

PaymentTrans

Trans WFlow

Training

TransferTrans

MultipleTrans/Cl

Stop Paymnt

AccountSetup

Account Inquiries

CreditCrdAdvncs

Cash Mgmt

Reports/Stats

Ticklers

Branch Locators

Fee Collection

Fraud Verificatn

Check Ordering

Hold Paymnts

OLAP

MarketngPlanner

Lead Generat

Sales Lead

A/c CntctHist

Demographics

CampgnMgmt

Agent Status

Customer Profiling

Selling Prompts

Override Procssng

Operator Profiles

Task Mgmt

Cross Selling

CustPersonlz

Consolidated view

What-if Calculatr

Referral Procssng

Contact Tracking

ComplntReportng

ComplntTracking

Decision TrackingDesktop Functns

StatemntPrinting

PaymentTrans

Trans WFlow

Cust ID with PIN

TransferTrans

MultipleTrans/Cl

Stop Paymnt

AccountSetup

Account Inquiries

Reports/Stats

Branch Locators

Fraud Verificatn

OLAP

A/c CntctHist

CustPersonlz

Contact Tracking

PaymentTrans

Trans JrnlTrans WFlow

Cust ID with PIN

TransferTrans

MultipleTrans/Cl

Stop Paymnt

AccountSetup

Account Inquiries

Reports/Stats

Branch Locators

Fraud Verificatn

Check Ordering

CustPersonlz

Consolidated view

StatemntPrinting

PaymentTrans

Contact Tracking

CshMngAccounts

Credit Cards

Comm. Accounts

Time Deposits

InvstmntAccounts

RetirmntAccounts

MortgageBrokeragAccounts

Savings Accounts

DDAAccounts

MMA Accounts Line of Crdt

SignatrVerificat

Workstation Configuration

Access Control Navigation & Workflow

Content Management



Content Management



Content Management



Content Management



Content Management

Cash Counting

Personalization

IVR routing

Branch Call Center ATM IVR Online

Source: CTOgroup


Targeting $12 Million Savings with SOA

2.4

0.6

0.8

4.0

1.1

1.0

0.6

1.6

4.3

0.4

0.4

0.8

1.6

1.3

1.8

0.3

0.3

0.1

0.2

0.1

0.2

0.2

0

2

4

6

8

10

12

14

ATMTotal: $1.815% total

BranchTotal: $4.739% total

CC/IVRTotal: $2.117% total

Interne t BankTotal: $3.529% total

TotalTotal: $12.1

Ann

ual I

T sp

end

(mill

ions

)

Legacy Data Access Potential duplication that can be eliminated: 50%-75%

Workflow Management Potential duplication that can be eliminated: 50%-75%

Data Services Potential duplication that can be eliminated: 25%-50%

Business Logic Potential duplication that can be eliminated: 25%-50%

User Interface Potential duplication that can be eliminated: 25%-50%

A ll c hanne ls 2 0 0 3

Duplicationbenefits areincrementalto benefitsfrom Leapfroginitiative

Source: CTOgroup


Reducing Redundancy with Shared Services

Source: CTOgroup

14


Portfolio of Plans for Projects Relevant to Business Domains

Plan

Review

SOA

Tooling &Design

Build

Iterative

Overlapping

Multi-level

Functional Architecture

Technical Architecture

Retail Bank Plan

Renovate Stage

Rationalize Stage

Enhance Stage

Stage 1 Stage 2 Stage 3

Source: CTOgroup


Building SOA the Right Way: Take an Iterative Approach

• Top-down only: have the plan, may not be able to execute

• Bottom-up only: build Services, may not be reusable

• SOA planning must be both– Develop the vision (but not the

details) ahead of time– Service development should be

iterative


How Do You Eat an Elephant?

• One bite at a time!

• Don’t expect to have all the answers on day one

• Take a step-by-step approach

• Show business value at each step

15


Thank You!


1

Dave McFarlane, COO, [email protected]

Steve Hansen, Solution Architect, [email protected]

Nexaweb Technologies Inc. www.nexaweb.com

Solving the Last Mile of SOA with

Enterprise Web 2.0

Web 2.0 Fever…..

D

The Enterprise Web 2.0 Opportunity

Empower End Users•Higher productivity•Higher flexibility

Empower Enterprise IT•Governance, security•Open Architecture

Empower Business•Business agility•Engaged customers

2

Business DriversIncrease Market Reach

– Remove IT barriers to market adoption– Convert more customers with rich clients– Adopt new SaaS business models

Gain Competitive Agility– Reduce time-to-market for

products/services– Increase user productivity and agility– Leverage M&A or 3rd party assets

Reduce Costs / Realize ROI– Deliver on the ‘Last Mile’ of SOA– Lower maintenance costs– Homogenize and simplify development Reusable

Services

Reusable Business

ComponentsBackend DataUnified View

“The Long Tail”

Legacy/1.0/AJAX Enterprise Web 2.0

Client/ServerMainframe,Midrange

Web 1.0

UI

internet

UI Logic

Biz Logic

Data

UI

UI Logic

Biz Logic

Data

UI

UI Logic

Biz Logic

Data

UI LogicUI

UI Logic

Biz Logic

Data

Data

UI

UI Logic

Biz Logic

Biz Logic

Data

UI

UI Logic

Biz Logic

Data

internet internetinternet

Secure Messaging, On/Offline

Com

plex

clie

nt fr

amew

orks

IMB

Re-u

se e

xist

ing

code

Java

Virt

ual M

achi

neHT

TP/S

J2EE

Ser

ver

Modernize

Clie

nt/S

erve

r Fle

xibi

lity

What is Enterprise Web 2.0?

Mission Critical Applications over the Web

• Complex, dynamic workflow• Dynamic data visualization• Varying user platforms• Large and/or real-time data

throughput• Offline capability and bandwidth

constrained• Composite applications• Desktop performance in a web

application• Rapid development, easy

maintenance• Short release cycles

UI

UI Logic

Biz Logic

Data

Data

UI

UI Logic

Biz Logic

Biz Logic

Data

UI

UI Logic

Biz Logic

Data

internet internetinternet

Secure Messaging, On/Offline

Com

plex

clie

nt fr

amew

orks

IMB

Refa

ctor

for p

erfo

rman

ce

Clie

nt/S

erve

r Fle

xibi

lity

3

Nexaweb Technologies• Mission

– Bring together RIA, SOA and legacy systems to deliver business-critical, composite applications over the Web.

– Leverage existing code, tools and development infrastructure to provide a better way to build, deploy and maintain business applications.

• Market Status– 5,000 enterprise deployments of business-

critical applications.

– Global footprint with offices in Burlington, MA and Tokyo Japan

Interactive Demonstration

Nexaweb PlatformNexaweb Platform:

• Unified:Technology and platform independent

• Simplified:WYSWYG, drag & drop, declarative XML GUI

• Open: Eclipse based plug-in supports J2EE development standards

4

Model-View-Controller (MVC) FrameworksNot distributed

Data Sources

Model

View

Controller

View

Controller

XHR

Model

View

Controller

View

Model

View

Controller

Client/Server Web 1.0 AJAX

Model

View

Controller

Model Controller

Clear separation & distribution

Nexaweb’s Distributed MVC Framework

Model

View

Controller

Model Controller

Data Sources

What is the Big Deal?• Reduces network traffic by

distributing business logic and by updating at the sub-object level

• Improves performance and application response time

• Enables client side business logic

• Enables disconnected operation

• Separates Model, View and Controller to improve maintainability as application evolves

• Achieves Enterprise Web 2.0 !

The IT Landscape

Web

Deve

lopm

ent T

ools

Met

hodo

logy

/Pro

gram

min

g M

odel

Server LogicTier

PHPHTTP J2EE.NET

Integration Tier

SOAPESB BPEL JDBC

Data andIT Systems

DBCRM LegacyERP

Client Tier

Ajax Java .NET Offline

HTTP Web Tier

HTTP/S Pub/sub ReliablePush


Pub/sub ReliablePush

Painful, expensive custom coding

The IT Landscape: Complex/Lots of Coding…

5

Serv

ice

Con

sum

ptio

nEn

terp

rise

Web

2.0

Serv

ice

Prov

ider

sSO

A a

nd L

egac

y

Enterprise Web 2.0 Reference Architecture

Deve

lopm

ent T

ools

HTTPWeb Tier

Pub/subHTTP/S ReliablePush

Data and ITSystems

DataCRM LegacyERP

IntegrationTier

SOAPESB BPEL JDBC

Prog

ram

min

g m

odel

/pro

cess

/met

hodo

logy

Server LogicTier

PHPHTTP J2EE.NET

Enterprise Mashup Server

Internet Messaging Bus (push, pub/sub, reliable)

Client Tier

Ajax Java .NET OfflineClient Container (Ajax, Java, .NET ,Offline)

Reduced, simplified custom coding

Deve

lopm

ent T

ools

Serv

ice

Con

sum

ptio

nEn

terp

rise

Web

2.0

Serv

ice

Prov

ider

sSO

A a

nd L

egac

y

Sample Impl. of Ref Architecture

IBM

RA

D/W

SAD/

Eclip

se(W

ebTo

ols,

…)

HTTPWeb Tier

Pub/subHTTP/S ReliablePush

Data andIT Systems

DataCRM LegacyERP

IntegrationTier

SOAPESB BPEL JDBC

Prog

ram

min

g m

odel

/pro

cess

/met

hodo

logy

Server LogicTier

PHPHTTP J2EE.NET

Client Tier


Nex

aweb

Stu

dio

IBM Websphere Server

Websphere Integration MQ, ESB, SOAP, CICS, etc.

Reduced, simplified custom coding

Universal Client Framework

Enterprise Data Services

Internet Messaging Bus

Nexaweb

Platform

Dec

lara

tive

Mar

kup

Q & A

1

Copyright © 2005, ZapThink, LLC

Practical SOA for Government:The SOA Roadmap

Ronald Schmelzer Senior AnalystZapThink, LLC


We’ve had IT challenges for years …


… but even after yesterday’s promises…

2


… we still have the same IT mess, only worse.


There’s Got to Be a Better Way!

Rather than trying to simply throw more software and Rather than trying to simply throw more software and iron at the problem, we need a better way of organizing iron at the problem, we need a better way of organizing our IT resourcesour IT resources

• Service-Oriented Architecture (SOA) represents a fundamental evolution in the IT industry

– The core business motivation is business agility.– Rather than “rip and replace” old systems – make them

work better together– We don’t want more middleware for our middleware– As fundamental a change as mainframe to client/server or

client/server to the Internet


Level Set – What is SOA?

• SOA is architecture – a set of best practices for the organization and use of IT

• Abstracts software functionality as loosely-coupled, business-oriented Services

• Services can be composed into business processes (which are also Services) in a declarative manner

3


Service-Oriented Architecture

• The Definition:– An approach to building and managing distributed computing

infrastructures that considers IT resources as Services available and discoverable on a network.

• The Implication:– Rather than dealing with isolated systems that must be

integrated after the fact, Service Orientation provides business users with understandable Services they can call upon and compose into business processes as needed – building systems that can adapt as the business changes.

• The Benefit:– The Service Orientation vision is therefore one of providing the

business values of agility and flexibility for users of technology, coupled with an abstraction layer that simplifies the complexity of today’s heterogeneous IT environments from those users.


SOA shifts the way we think

Compose ServicesIntegrate Silos

Loosely Coupled, Agile and Adaptive

Tightly Coupled

Designed to changeDesigned to last

Favors Heterogeneous TechnologyFavors Homogeneous Technology

Architecture makes it workMiddleware makes it work

Business centeredCost centered

Interactive and iterative development

Long development cycle

Process OrientedCode Oriented

Service Oriented ArchitectureTraditional Distributed Computing


The Benefits of SOA…

Reduced cost of integration

Improved value from legacy applications

Reuse leading to reduced redundancy

Greater visibility for governance & compliance

Increased reuse of software assets

Business agility…– Respond quickly & efficiently to business change– Leverage change for competitive advantage

4


SOA Hotspots

• Four key areas of SOA investment– Reduction in integration expense– Increase in Service / asset reuse– Increase in business agility– Enablement of governance &

compliance

• Key Problem areas– EAI replacement– Legacy enablement/migration– Shared Service development– Governance– Embedding processes in the

extended enterprise


The Challenges with doing SOA right

• Architecture? Sounds difficult!• Performance issues around XML• New tool and infrastructure requirements

– Messaging– Contract development– Composite application development– Metadata management– Policy infrastructure

• But… doesn’t this infrastructure already exist?


The ZapThink SOA Roadmap

5


ZapThink’s SOA Implementation Roadmap

Heterogeneous Systems with Proprietary Interfaces

Manage Services

Implement the SOA Metamodel

Service-Oriented ProcessSemantic Integration

Dynamic Service Discovery

Secure Service Interfaces

Wrap Legacy Systems in Services Interfaces

Service-Oriented Enterprise

Enterprise SOA Buildout

Mission-Critical SOA

SOA Pilots

“Grass Roots” Web Services Implementations

Create a Governance Framework

Contract-First Development

Cross-Departmental SOA


SOA Pilots

• A few high ROI Services• Build acceptance for SOA• Get team up to speed• Work out the kinks• Pilot the governance model• Part of an iterative approach to SOA

• Piloting only the Services instead of the architecture• Remember, the pilot is one step on the roadmap

DANGER! Avoid the SOA Pilot PitfallDANGER! Avoid the SOA Pilot Pitfall


Building SOA the Right Way

• SOA is all about continuous and sometimes unpredictable change

• Development issues

– How to handle versioning?

– How to handle metadata management?

– How to develop changing policies?

• Runtime issues

– Service availability

– Policy enforcement

– Guarantee service-level agreement

– Maintain low TCO

6


Service Domains

• A Service Domain is a logical grouping of shared Services with a common business context

• Manage Services by managingthe Domains

• Move away from traditional IT silos


Role of the Architect

• Where is the architect?– Growth of the Enterprise

Architecture Team

• Should have dotted-line responsibility to the CIO– Avoid the Ivory Tower!

• Become the Master of Best Practices– Know the methodologies and approaches– Best practices, not software, is where the

innovation and opportunities remain!


Ownership of Services

• Shared Services cross organizational boundaries

• Siloed IT management styles are becoming obsolete

• The new role for enterprise architects

7


How do you Budget?

• Who pays for Service development?

• Who pays for Service changes?

• Should architects have their own budget?

Revenge of the Revenge of the chargebacks!chargebacks!


Planning for Change

• Why middle management is resisting

• How enterprise architecture helps

• Incremental SOA is the way to go!


Risk & Control

• Effective managers must delegate responsibility, yet maintain control

• “Micromanagement” rarely effective, doesn’t scale

• IT both a curse and a blessing

• SOA greater visibility greater control

8


Service-Oriented Process

• Processes that are coarse-grained: composedof Services and exposed as Services

• Processes that are loosely coupled: a change to a process flow, activity, subprocess doesn’t effect other processes

• Processes that are asynchronous• Processes that are dynamically discoverable

PROCESSES THAT CAN RESPOND TO CHANGE


• What does it mean to build business logic in metadata?

• The power is not the interface specification, but in the Service abstraction

• Code meets requirements of contracts – but does not specify a contract of its own!

J

Fundamental Idea: Business Logic in Metadata

Source: Copyright © 2002 ZapThink, LLC

ContentManagement

Web Site

File System

RDBMS

Office Documents

B2B Exchanges

Directory

ERP / CRMSystems

Mainframe / Legacy

NetworkedDevices

No

N- o

r S

EM

I-S

TR

UC

TU

RE

D

ST

RU

CT

UR

ED

Source: IBM


Role of Composite Applications

• Architecture guides composition of Services

• Legacy assets key part of Service-oriented composite apps

• Challenge: top-down process first or bottom-up system first?

• Benefit: combine old legacy processes with new composite business logic

9


Semantics: The Greatest Challenge of SOA

• Just because you can call someone, doesn’t mean you can speak their language

• Adds layers of complexity to the transformation problem


The Service-Oriented Enterprise

• IT resources are available on demand to businesses as Services

• The Service-oriented abstraction layer enables companies to run their operations and conduct business with each other in a dynamic and automated fashion

• Business drives IT, and agile IT enables agile businesses


Thank You!

ZapThink is an industry analysis firm focused exclusively on XML, Web Services, and Service-Oriented Architecture.

Ronald Schmelzer

[email protected]


• Go to www.zapthink.com/credit and enter the code ZASOAI.

• Download a digital copy of the presentation

• Sign up for our ZapFlash newsletter

Take Credit for attending this presentation!

1

W W W . I T K O . C O M1 © 2007, iTKO, Inc. | All rights reserved.

Federated SOA – better utility through trust


SOA: The promise

• Business Value Proposition:• Agility through the ability to automate business processes in a highly

dynamic fashion through loose coupling

• Technology Value Proposition:• Service Reuse, leading to better utilization of IT resources and

quicker response to IT customers

Value = (NSR*DR) * C


FEA Example – Cross Agency

2


Outsourcedsupplier

Transactionprovider

PartnerReseller

Customerbuyer

Your World

Division 1

Division 2

The Vision - Seamless, interoperable services

Cross functional processes, workflows.


Transaction service

Datawarehouse

BI tools

Your AppWorkflow

Channel Partner

RMI objects

Customer company

CRM Web App

BusinessRules

Outsourced firm

Legacy App

SOAP objects

Web Services

.NET OrderingService

ContentDatabaseLegacy App

Web interface

Messagingservice

File System

Legacy Data

Division2

FinancialsMainframe

Division 1

Your Company

ESB

Exposing services hides complexity


Challenges

• Services may not exist

• Services may exist, but you may not be aware of them

• Services may not exactly meet your requirements

• Services can change, and break

• Services may not be secure, or may not be available, or may not scale

• Services could be built on many technologies

• Services can ‘run amok’

The answer is: SOA GOVERNANCE(What was the question?)

3


Vertical Governance = Piece of Cake

For vertical hierarchies within organizations, there is an expected level of shared trust.

Higher level can expect the underlying development team to “build to order” IT functionality for it

Service development team can expect the consumer to leverage the service according to understood business requirements

Business UnitBusiness Unit Business Unit

Division DivisionDivisionDivision Division Division

Group Group Group GroupGroupGroupGroupGroupGroup

TeamsTeams


Horizontal Service Reuse = Anarchy

Across different business units, coordinating the use of a service is difficult.

Service Providers want to establish reuse of services, but they are answerable to different stakeholders

Upstream Consumers of services do not provide clear enough Use Cases of how they will employ services

Therefore teams build redundant functionality

Business UnitBusiness Unit Business Unit

Division DivisionDivisionDivision Division Division

Group Group Group GroupGroupGroupGroupGroupGroup


Criteria for Acceptance into CORE.gov• Components and services proposed for inclusion in CORE.gov are evaluated for acceptance based

upon the following criteria:

• The component or service must be reusable, in that it can be incorporated (in the case of a developmental candidate, has the potential to be incorporated) into a new or existing system or capability, or by itself provide a service to a customer agency (e.g., the e-Payroll program offers a choice of three payroll services that are used directly by Federal agencies). Any licensing requirements or other restrictions must be clearly stated. For some types of components/services, an inter-agency Memorandum of Understanding may be needed.

• The component or service must have the potential of providing, through reuse, significant value for the time invested in re-using the component or service.

• The component or service must be mapped to the Federal Enterprise Architecture (FEA) Business Reference Model (BRM), Service Component Reference Model (SRM) and/or Technical Reference Model (TRM), depending upon the nature of the component or service, i.e., whether it is an online electronic business process, technical entity, etc.

• Candidate production components or services must have been used in a production environment and their quality described by the owning agency on the CORE.gov application form.

• Candidate components or services must have successfully completed the IT Security Certification and Accreditation (C&A) process or the status of completing the C&A process must be noted.

• The CORE.gov application form for the candidate component or service must be filled in with all required fields. The information entered must be clear, understandable, and accurate.

• The owning agency must agree to provide updates to the information about a component or service in CORE.gov within five business days of any change to the component or service.

Core.gov acceptance application

4


Governance Provides for Horizontal Trust & Transparency• Key function is policy definition, modeling, and enforcement

• Three kinds of policy can be automated• Structural -- compliance to standards -- ‘the pin-outs’• Behavioral -- honoring functional expectations• Performance -- honoring performance / reliability expectations

• Critical to establish an environment that provides this, often federated across the organization(s)• Top level SOA COE built from participants• Clearly defined Publish & Consume Processes• Visibility to clearly identify root causes

via reporting, alerting, dashboards

• We call this SOA Testing

SOAGovernance


Trust Requires: “Three C’s” of SOA Testing

Complete Testing• Every heterogeneous layer of

architecture• Test UI verify in system of record• Reuse functional test for

performance testing

Collaborative Testing• Test early before UIs are created• Not just dev, business analysts and

QA should verify processes

Continuously Test• Regress on existing functionality• Add testing of new services to

existing testing workflows

Complete >single component all technologies

Continuous >Phased tests constant testing

Collaborative >Dev/QA test silos everyone tests, every phase


“Complete” Example – FEA TRM

5


“Complete” Example: Fortune 100 Financial Company


SOA and Web Services (or JBOWS 2.0)• OASIS - SOA does not equal Web

Services • Web services can be used to

implement SOA• Service Orientation does not require

use of Web Service protocols• Web Services protocols do not ensure

the overall system is SOA

• SOA projects may start by testing at web services level• But only 10-20% of SOA tests produced

are web services tests!

• Web Services testing is to SOA what UI Testing used to be to traditional Application Testing

SS SOA


“Collaborative” – Involve all players

6


Continuous Integration = Continuous Testing

Component/Service Teams

Development

QA/QE

Pre-production

Production

product component product component

Dev build

test bed

Staging

Production

Dev build

test bed

Con

tinuo

us S

OA

Tes

t Pla

tform


SOA “Publish” Cycle

1. Offer

2. Certify

3. Verify

ServiceRepositories

ContinuousTesting

Candidateservices

ComponentTesting

StructuralBehavioralPerformance(PSR)

Metrics &Alerts monitoring Check in

Policy tests

Repairissues

4. Review


SOA “Consume” Cycle

1. Discovery

3. ValidateWorkflow2. Confirm

Workflow

ContinuousTesting

Discover &Assemble Certified& CandidateServices

Return Workflows& Policy Violations

BehavioralPerformance

Process-levelTesting Check in

Policies &Tests

ServiceRepositories

4. Alerting

7

W W W . I T K O . C O M19 © 2007, iTKO, Inc. | All rights reserved. 19

User/Entity

Allied/ Coalition& Multi-national

(Limited)

Strategic/Operational

Enterprise PortalEnterprise Portal Content Content Discovery & DeliveryDiscovery & Delivery

Enterprise Enterprise CollaborationCollaboration

Service Oriented Architecture FoundationService Oriented Architecture Foundation

DoD portion of the

Intelligence Mission Area

DoD portion of the

Intelligence Mission Area

Business Mission Area

Business Mission Area

Warfighting Mission AreaWarfighting

Mission Area

Information Exchange

The NCES Core Enterprise Services deliver the capabilities that support and enable the Business, Warfighting, and Intelligence Mission Areas to

achieve network-centric operations. 19

Limited Tactical

Core Enterprise Services

Defense Example - NCES Increment I


Benefits to NCES

NGADIA

NRO NSA

Command& Control

Intelligence Warfighter Business

SituationalAwareness

FocusedLogistics

Data

ForceProtection Mission

Planning

Insufficient synchronous collaboration

JTF HQ

COCOM

Mission Areas: Battlespace Awareness,Force Application, Force Protection

Mission Areas: Focused LogisticsMission Areas:Battlespace Awareness

StateMaritime

Land SoFAir

DepotsLog Bases

TRANSCOM

Industry

Observe

Orient

ActDecide

NGADIA

NRO NSA

Intelligence Warfighter Business

JTF HQ

COCOM

Mission Areas: Battlespace Awareness,Force Application, Force Protection

Mission Areas: Focused LogisticsMission Areas:Battlespace Awareness

StateMaritime

Land SoFAir

DepotsLog Bases

TRANSCOM

Industry

� Mission Planning� Situational Awareness

� Logistics� Force ProtectionShared Space

COICOI

COI COICOI

COICOI

COI

Shared, accessible information = Small OODA Loop

Pre-NCES OODA Loop“As-Is” Environment

ObserveOrient

Act

Post NCES OODA Loop

Decide

“To-Be” EnvironmentStove-piped information = Large OODA Loop

NCES creates a shared information space, increasing decision velocity


It’s all about Trust

• Governance needs testing to provide visibility and enforcement of policy

• Visibility and enforcement allow service consumers to develop trust of services

• Trust leads to more frequent reuse and better utility of services

• Better utility and reuse, along with interoperability, are the base elements that allow services to be loosely coupled

• Loosely coupled services lead to better Business Agility

8


About iTKO

1999 . 2003 . 2005 . 2006 .2001.

1999 – iTKO Incorporates (Privately Held)

2001 – LISA under development – (4) Patents Pending

2003 – LISA 1.0 Released to Market

2004 – LISA 2.0

2006 – LISA 3.0

2004 .

Our Mission: Everyone should own quality™.

• Focused LISA on Services-Based Testing (before SOA)

• Leading SOA/SOBA Testing Framework


Thank you for your interest• Summary and Q&A

• Grab a copy of our white paper!

• For more info:• URL: http://www.itko.com• 877-BUY-ITKO• Download WS-Testing for free,

or request a deeper SOA evaluation• Blog: http://itko.blogspot.com• Email: [email protected]

PS – FEA on the web:http://www.whitehouse.gov/omb/egov/a-1-fea.html