This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• 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
Copyright 2007 The Linthicum Group, LLC
Understanding the Forces at Work
SOA
SaaS
Web 2.0
Emerging Standards
Hype
Enterprise Architecture
Cost Reduction
Copyright 2007 The Linthicum Group, LLC
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.”
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
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?
Copyright 2007 The Linthicum Group, LLC
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. “
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
15
SOA and the FEA
FEAFEA
Data ReferenceModel
Data ReferenceModel
BusinessReference Model
BusinessReference Model
Service ComponentReference Model
Service ComponentReference Model
Technical Reference Model
Technical Reference Model
PerformanceReference 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
BusinessReference Model
BusinessReference Model
Service ComponentReference Model
Service ComponentReference Model
Technical Reference Model
Technical Reference Model
PerformanceReference Model
PerformanceReference Model
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
BusinessReference Model
BusinessReference Model
Service ComponentReference Model
Service ComponentReference Model
Technical Reference Model
Technical Reference Model
PerformanceReference Model
PerformanceReference Model
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
BusinessReference Model
BusinessReference Model
Service ComponentReference Model
Service ComponentReference Model
Technical Reference Model
Technical Reference Model
PerformanceReference Model
PerformanceReference Model
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
Copyright 2007 The Linthicum Group, LLC
JBOWS vs. SOA
• JBOWS = Just a Bunch of Web Services.
• SOA = Use of services to form solutions quickly and easily.
Copyright 2007 The Linthicum Group, LLC
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
Understand your business objectives and define success.
ROIROIDefine ROI
Create Business Case
BusinessCase
BusinessCase
Copyright 2007 The Linthicum Group, LLC
Define your problem domain
SystemDescriptions
SystemDescriptions
System Complexity Analysis
SOA POC
POCResults
POCResults
DomainDescriptions
DomainDescriptions
Vendors
Copyright 2007 The Linthicum Group, LLC
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
RDBMS XML Docs Flat FilesPackaged Apps
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
RDBMS XML Docs Flat FilesPackaged Apps
Data Warehouses
Data Warehouses
RDBMSRDBMS XML DocsXML Docs Flat FilesFlat FilesPackaged Apps
Packaged Apps
ExistingData
DataServices
Layer
BusinessApplications
ReportingDashboards Composite Apps
BusinessApplications
ReportingDashboards Composite Apps
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
RDBMS XML Docs Flat FilesPackaged Apps
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
RDBMS XML Docs Flat FilesPackaged Apps
Data Warehouses
Data Warehouses
RDBMSRDBMS XML DocsXML Docs Flat FilesFlat FilesPackaged Apps
Packaged Apps
ExistingData
DataServices
Layer
BusinessApplications
ReportingDashboards Composite Apps
BusinessApplications
ReportingDashboards Composite Apps
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
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
Understand all processesin your domain.
CandidateProcesses
CandidateProcesses
Process analysis.
Define metadata, services,and processes
Processes,Services,
AndInformation
Processes,Services,
AndInformation
Process integrationanalysis.
ProcessIntegrationDiagrams
ProcessIntegrationDiagrams
CandidateServices
CandidateServices
ExternalProcesses
(B2B)
ExternalProcesses
(B2B)
SOAMetadata
SOAMetadata
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
Define new services.
CandidateProcesses
CandidateProcesses
Service definition.
Service design.
Processes,Services,
AndInformation
Processes,Services,
AndInformation
Service implementation.Process
IntegrationDiagrams
ProcessIntegrationDiagrams
SOAMetadata
SOAMetadata
CandidateServices
CandidateServices
ServiceDefinition
ServiceDefinition
ServiceDesign
ServiceDesign
ServiceImplementation
ServiceImplementation
Copyright 2007 The Linthicum Group, LLC
Define new processes.
CandidateProcesses
CandidateProcesses
Process definition.
Process design.
Processes,Services,
AndInformation
Processes,Services,
AndInformation
Process implementation.Process
IntegrationDiagrams
ProcessIntegrationDiagrams
MetadataMetadata
CandidateServices
CandidateServices
ProcessDefinition
ProcessDefinition
ProcessDesign
ProcessDesign
ProcessImplementation
ProcessImplementation
Copyright 2007 The Linthicum Group, LLC
Select your technology set.
TechnologyRequirements
TechnologyRequirements
Define requirements.
Technology analysis.
Technologysolution
Technologysolution
Vendors
Define candidate technology.
Technology selection.
Technology validation.
Copyright 2007 The Linthicum Group, LLC
The Realities– Standards
• Too many to track• WS-*
– Technology• Service management• Governance• Data abstraction and the Database• Orchestration/Process• Emerging Stuff
Copyright 2007 The Linthicum Group, LLC
Service management
• Tracking services through design, development, deployment, and testing.
• Core components:– Repository– Service control– Links to security– Designer
Copyright 2007 The Linthicum Group, LLC
Governance
• Manage access and policy at the services level.
• Core components:– Directory– Repository– Policy management engine– Links to security– Service maturation
Copyright 2007 The Linthicum Group, LLC
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”
Copyright 2007 The Linthicum Group, LLC
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
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”
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
Understand Outside Interfaces
New Accounts
Finance/ Operations
CommissionCalculation
Sales
DataCleaning
On DemandApplications and Service Markets
Best Practices asShared Processes
Sales Order Update
SOA
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
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
Copyright 2007 The Linthicum Group, LLC
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.
Copyright 2007 The Linthicum Group, LLC
Thanks!
• Blogs:– eBizq.net “Linthicum Channel”– InfoWorld “Real World SOA”– Intelligent Enterprise “SaaS Advisor”
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
• 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
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
• 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
• 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
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.
• 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.
• 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)
• 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!
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.
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
• 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.
• 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
• 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
• 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
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.
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