Steps to SOA Success

1. Steps to SOA Success David S. Linthicum david@linthicumgroup.com www.linthicumgroup.com

2. References • Blogs: • eBizq.net “Linthicum Channel” • InfoWorld “Real World SOA” • Weekly Podcast • InfoWorld SOA Report • Columns • Web Services Journal • Business Integration Journal • You can download this presentation, and the 12 Steps to SOA at www.linthicumgroup.com.

3. 1995 2000 2006 Integration of Internal Systems Integration with External Systems Pervasive Integration SOA SaaS/Web Services Web 2.0

4. Current State of Things…Real World • 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 creating a business case. • Using the wrong people. • Lacking funding and empowerment.

5. Why SOA Fails • The enterprise/agency considers SOA a project versus what it is; a more holistic notion. • They use 2nd tier talent. • They are under-resourced. • They allow the vendors to define their solution. • Requirements are not fully gathered.

6. 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 are having either "significant difficulties" (27 percent) or "can't keep up at all" (9 percent).” • CIO Magazine

7. SOA to the Rescue?Goals and Characteristics of a 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

8. SOA Meta Model Security Monitoring/Event Management Governance Process/Orchestration Services Data Services/Messaging Data Abstraction Data Data Rep Legacy Legacy Internet-Based Services New Services

9. 5 Ways to Make Your SOA a Success • Understand the pain. • Define the value. • Focus on understanding (Steps to SOA). • Remember the people. • Focus longer term.

10. Understand your business objectives and define success. • The technology you layer into that business should add value by supporting that business’ objectives and facilitating efficiencies. • The technology should help improve the bottom line. • Thus, it’s very important to define these objectives up front, including the goals for business success.

11. Understand your business objectives and define success. ROI Define ROI Business Case Create Business Case

12. Define your problem domain. • You can’t boil the ocean, thus you must define the scope of your SOA, within an enterprise. • Most SOAs are best implemented in small steps, such as moving a single division, or portion of a division, to SOA, if needed, instead of an entire enterprise all at once. • You need to establish the demarcation lines at the beginning of the project to provide better focus and understanding. • Remember, a POC will have a POC domain.

13. Domain Descriptions Define your problem domain System Descriptions System Complexity Analysis POC Results SOA POC Vendors

14. Understand all application semantics in your domain. • You can’t deal with information you don’t understand, including information bound to behavior (services). • It is extremely important for you to identify all application semantics—metadata, if you will--that exist in your domain, thus allowing you to properly deal with that data.

15. Understand all application semantics in your domain. SOA Metadata Legacy Metadata Meta data analysis Data Abstraction Layer External Metadata (B2B) Data abstraction layer definition Data Services Data services definition

16. Understand all services available in your domain. • Service interfaces are quirky. They differ greatly from application to application, custom or proprietary. • What’s more, many interfaces, despite what the application vendors or developers may claim, are not really service interfaces at all, and you need to know the difference. • Services provide behavior as well as information, thus they are service-oriented. • There are some services that just produce information; those are information-oriented and should not be included in this step. • It is important to devote time to validating assumptions about services, including: • Where they exist. • The purpose of the service. • Information bound to the service. • Dependencies (e.g., if it’s a composite service). • Security issues.

17. SOA Metadata Understand all services in your domain. Candidate Services Legacy Services Service analysis Services And Information External Services (B2B) Metadata and services analysis Services And Performance Performance analysis

18. Understand all processes in your domain. • You need to define and list all business processes that exist within your domain, either automated or not. • This is important because, now that we know which services and information sources and sinks are available, we must define higher level mechanisms for interaction, including all high-level, mid-level, and low level processes. • In many instance, these processes have yet to become automated or are only partially automated.

19. Understand all processes in your domain. SOA Metadata Candidate Processes Process analysis. Candidate Services Processes, Services, And Information Define metadata, services, and processes External Processes (B2B) Process Integration Diagrams Process integration analysis.

20. Define new services and information bound to those services. • You must define all new services that are to make up your SOA, these will fall into one of three categories. • First are services exposed out of existing systems, or, legacy services, such as ERP, CRM, legacy, etc.. • The second type of services are composite services, which are services unto themselves that are made up of many different services. • Finally, scratch built services are services that are built from the ground up to be a true service.

21. Processes, Services, And Information Define new services. Candidate Services Service Definition SOA Metadata Service definition. Service Design Candidate Processes Service design. Service Implementation Process Integration Diagrams Service implementation.

22. Define new processes, as well as services and information bound to those processes. • At this point we should understand most of what is needed to define new processes, as well as bind them to existing processes, and automate processes previously not automated. • New processes should be defined that automate the interactions of services as well as information flows to automate a particular business event or sets of events. • While you can define some very complex logic within new processes using today’s tools, the theme here is to orchestrate existing services and information flows rather than create new functionality. • In essence, it’s a meta-application that sits on top of many smaller applications, defining interactions from lower to higher levels.

23. Processes, Services, And Information Define new processes. Candidate Services Process Definition Metadata Process definition. Process Design Candidate Processes Process design. Process Implementation Process Integration Diagrams Process implementation.

24. Select your technology set. • Many technologies are available, including application servers, distributed objects, and integration servers. • The choice of technology will likely be a mix of products and vendors that, together, meet the needs of your SOA. • It is very rare for a single vendor to be able to solve all problems--not that that reality has ever kept vendors from making the claim that they can. • Technology selection is a difficult process which requires a great deal of time and effort. • Creating the criteria for technology and products, understanding available solutions, and then matching the criteria to those products is hardly a piece of cake.

25. Select your technology set. Technology Requirements Define requirements. Define candidate technology. Technology analysis. Technology solution Technology selection. Technology validation. Vendors

26. Deploy SOA technology. • This is the “just do it” step, meaning that you’ve understood everything that needs to be understood, defined new services and processes, selected the proper technology set, and now it’s time to build the thing.

27. Test and evaluate. • To insure proper testing, a test plan will have to be put in place. • It is really just a step-by-step procedure detailing how the SOA will be tested when completed. • A test plan is particularly important because of the challenges in testing an SOA solution. Most source and target systems are business-critical and therefore cannot be taken offline.

28. Final Words • Pay me now, or pay me later. Make sure you do it right the first time…get the help you need. • Don’t be afraid to experiment, and admit you’re wrong…backup and try again. • Keep your vendors working with you. • Empower those working, so they can work to get things done. Avoid politics, if possible. • Learn all you can, but don’t get caught up in the hype. • Put standards in their proper place. • Small battles win the war…Keep that in mind. • Give yourself plenty of time, never skimp on any of the steps.

29. Thanks!