Embed Size (px)
Citation preview
O p t i m i z i n g B u s i n e s s I n t e g r a t i o n & E f f e c t i v e n e s s T h r o u g h L e a d i n g - E d g e T e c h n o l o g i e s
A P U B L I C A T I O N
w w w . b i j o n l i n e . c o m N o v e m b e r / D e c e m b e r 2 0 0 6
Can SOA Finally Deliver on the Promise of Enterprise Integration?A L S O I N T H I S I S S U E
A B P M M a t u r i t y M o d e l : I m p o r t a n t f o r L o n g - L a s t i n g B P M S u c c e s s | P r o c e s s - B a s e d , S OX C o m p l i a n c e
E S B : P r o v i d i n g S y n c h r o n o u s A c c e s s t o A s y n c h r o n o u s L e g a c y S y s t e m s | B u l l e t p r o o f i n g Yo u r S O A
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.netTHE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net
SOA — Plan It: The SOA Strategic Services Blueprint page 4by Eric Roch
SOA — Build It: Creating Reusable Service Patterns page 5by Beth Gold-Bernstein and Brenda Michelson
SOA — Manage It: The Increasing Need for SOA Governance page 6by David A. Kelly
Buyer’s Guide starts on page 8
Buyer’s Guide
Buyer’s Guide starts on page 8
A Special Focus on SOA
Ready to move to SOA? ebizQ offers a complimentary training assessment for your organization! Go to http://www.ebizq.net/soaneeds
ebizqInsiderWinter06.qxd 11/8/06 5:49 PM Page 1
ebizQ Buyer ’s Guidebetween pages 24–41
contentsN o v E M B E R / d E c E M B E R 2 0 0 6 • v o l u M E 8 / N u M B E R 6 • w w w . B i j o N l i N E . c o M
a r t i c l e s
Having a BPM Matur i ty Model Is Impor tant for Long-Last ing BPM SuccessBy M ichae l M e le novsky & j i M s i n u r
Bul letproof ing Your SOA: F ive Keys for Secure SOA and Web ServicesBy B r ian roddy
ESB: Providing Synchronous Access to Asynchronous Legacy SystemsBy sh iva B haj e kar & ash ish kr ish na
F irst Impression: Governance—The Key to SOA Success By Tony M. B rown
SOA Governance FrameworkBy raMy aBaas
Can SOA F inal ly Del iver on the Promise of Enterpr ise Integrat ion?By jake fr e ivald
Introducing the OAS IS Reference Model for Service Or iented ArchitectureBy j e ff a. esTe fan
Making the Case for Process-Based, Sarbanes-Oxley Compl ianceBy j i M cole Man
Understanding the BPMN-XPDL-BPEL Value ChainBy naThan i e l PalM e r
ERP or NextGen SOA?By raj iv ToTlan i & vi kas Balakr ish na
Advancing SOA With Real-Time Events By ch r is gar n e r
Laying the Foundat ion for Enterpr ise Software In i t iat ives: Bidirect ional , Pure Play Adapters By arch i e roB oosToff
c o l u m n s
The F irst WordBy B oB ThoMas
Enterpr ise Integr i ty: Think BPMSBy davi d Mcg ove ran
Unconvent ional Wisdom: On Death and Dying—SOA Sty leBy daryl Plu M M e r The Next Wave: Ubiquitous Computing and SOABy davi d s. l i nTh icu M
Renaissance Man: A Memory for Process? I ’m St i l l Here! By davi d Mccoy
The Software Ecologist : Once Upon a TimeBy joh n sch M i dT
71015181942465054565962
46
14244164
� • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Teach old applications new tricks.
Read case studies about this exciting innovation at www.InterSystems.com/Enrich2E
© 2006 InterSystems Corporation. All rights reserved. InterSystems Ensemble is a registered trademark of InterSystems Corporation. 11-06 EnsEn2BIJ
Chances are you have users who want your applications to do new and wondrousthings. So you’ve probably tried rewriting them, and know how difficult that can be.
We have an easy way to enhance applications without rewriting – adding functionalityand new user interfaces, and giving your applications the capability to work together asan ensemble.
It’s not magic. It’s Ensemble – a software innovation by InterSystems that enablesyou to extend your applications with a browser-based user interface, adaptable workflow,rules-based business processes, executive dashboards, and more. In addition, Ensemblegives you the ability to rapidly connect people and processes.
We are InterSystems, a global software company with a 28-year track record ofinnovations that enrich applications.
Come learn new tricks at InterSystems' booth #3 at the Gartner AI & WS Summit in Orlando, FL, Dec. 4-6, 2006.
Teach old applications new tricks.
Read case studies about this exciting innovation at www.InterSystems.com/Enrich2E
© 2006 InterSystems Corporation. All rights reserved. InterSystems Ensemble is a registered trademark of InterSystems Corporation. 11-06 EnsEn2BIJ
Chances are you have users who want your applications to do new and wondrousthings. So you’ve probably tried rewriting them, and know how difficult that can be.
We have an easy way to enhance applications without rewriting – adding functionalityand new user interfaces, and giving your applications the capability to work together asan ensemble.
It’s not magic. It’s Ensemble – a software innovation by InterSystems that enablesyou to extend your applications with a browser-based user interface, adaptable workflow,rules-based business processes, executive dashboards, and more. In addition, Ensemblegives you the ability to rapidly connect people and processes.
We are InterSystems, a global software company with a 28-year track record ofinnovations that enrich applications.
Come learn new tricks at InterSystems' booth #3 at the Gartner AI & WS Summit in Orlando, FL, Dec. 4-6, 2006.
BIJ to Evolve Into Business Transformation & Innovation in 2007
I n my previous column, I alluded to the next evolution of Business Integration Journal (BIJ). Starting
in 2007, we’re evolving BIJ to the next level as a new magazine titled Business Transformation & Innovation (BTI). Targeted to the intersection of business and IT, Business Transformation & Innovation will be the first magazine of its kind to provide the “how-to” and “what works” information necessary for Senior Business Executives, Line-of-Business Managers, Senior IT
Executives, and IT Managers working together to quickly adapt to changing business needs, continuously innovate, and consistently gain and maintain a competitive advantage. IT organizations are being required to strategically align with the business and help provide innovative solutions that are necessary to transform today’s businesses into agile enterprises, ready to pounce on the next business opportunity, maintain a leadership advantage, or quickly overtake a competitor. We’re now in a business environment where timely information is critical and business processes must be streamlined to perfection. In short, today’s dynamic business climate requires enterprises to transform themselves into agile enterprises through innovation—or be left behind. Whether it’s how to improve business processes, integrate supply chain partners, understand the uses of Service-Oriented Architecture (SOA), better understand enterprise architecture, or deliver new services to customers, Business Transformation & Innovation will ask and answer the critical questions surrounding business transformation and innovation. For a sneak preview of the first cover of Business Transformation & Innovation—and to see some of the topics that will be covered in the first few issues—take a look at the page on your right. Because it’s basically a new magazine, all BIJ subscribers will need to subscribe anew to Business Transformation & Innovation (why not do it right now at www.btijournal.com). Physically, Business Transformation & Innovation will be a completely new and beautiful magazine, from the heavier cover and inside pages to the perfect binding and terrific matte finish. I sincerely think you’ll enjoy Business Transformation & Innovation and find it to be interesting and helpful. I bet you’ll especially love the “Wit & Wisdom” page at the end of each issue! You’ll be doing me a tremendous favor if you’d please let your IT and business colleagues know about Business Transformation & Innovation—you’ll also be doing them a favor. Have a great 2007! bij
B O B T H O M A S ,P U B L I S H E R , E D I T O R - I N - C H I E F
Business Transformation & Innovation Article Submission Guidelines: BTI accepts submission of articles on all aspects of business transformation. BTI writer’s guidelines are available by visiting www.btijournal.com. articles and article abstracts may be sent directly via e-mail to [email protected].
PublisherB o B T h o M a s b o b @ b i j o n l i n e . c o m9 7 � - 3 5 4 - 1 0 � 4
Associate Publisherd e n n y y o s T d e n n y @ b i j o n l i n e . c o m
Managing Editora M y B . n o v o T n y a m y @ b i j o n l i n e . c o m 3 5 � - 3 9 4 - 4 4 7 8
Sr. Technical Editor & Consulting Industry Analystd a v i d M c g o v e r a n m c g o v e r a n @ b i j o n l i n e . c o m
Editorial Advisory Boardd o u g l a s w . a l l e nd a v i d l i n T h i c u M d a v i d M c c o yd a v i d M c g o v e r a n
Online Services ManagerB l a i r T h o M a s b l a i r @ b i j o n l i n e . c o m
Copy Editorsd e a n l a M P M a nP a T w a r n e r
Art DirectorM a r T i n w . M a s s i n g e rm a r t i n @ b i j o n l i n e . c o m
Production Managerk y l e r i c h a r d s o nk y l e @ b i j o n l i n e . c o m
Advertising Manager—Westk a r i n a lT o n a g ak a r i n @ b i j o n l i n e . c o m7 1 4 - 9 7 4 - 0 5 5 5
Advertising Manager—Eastl e s l i e r i n g el e s l i e @ b i j o n l i n e . c o m� 1 5 - 3 4 8 - 7 8 7 0
Advertising Administratord e n i s e T . c u l l e r s————————————————————————————————————————————————
The editorial material in this magazine is accurate to the best of our knowledge. no formal testing has been performed by Business Integration Journal or Thomas communications, inc. The opinions of the authors do not necessarily represent those of Business Integration Journal, its publisher, editors, or staff.
————————————————————————————————————————————————
Subscription Rates: free subscriptions are available to qualified applicants in the usa only. due to the significantly higher postage costs, it is necessary to charge for annual subscriptions outside of the usa; canada and Mexico—$48, all other countries—$96 (all payments in u.s. funds).
————————————————————————————————————————————————
Inquiries: all inquiries concerning subscriptions, remittances, requests, and changes of address should be sent to:
Business Integration Journal,9330 lBj freeway, suite 800dallas, Texas 75�43voice: �14-340-�147e-Mail: [email protected]
————————————————————————————————————————————————
for article reprints, contact wright’s reprints at877-65�-5�95
————————————————————————————————————————————————
Publications agreement no. 40048088station a, Po Box 54windsor on n9a 6j5canada
————————————————————————————————————————————————
all products and visual representations are the trademarks/registered trademarks of their respective owners.
————————————————————————————————————————————————
Thomas Communications, Inc. © �006. all rights reserved. reproductions in whole or in part are prohibited except with permission in writing. (Business Integration Journal issn 155�-�3�6)
————————————————————————————————————————————————
t h e f i r s t w o r d
4 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Targeted to theIntersection of
Business and IT.
Business Transformation & Innovation (BTI) is a new bi-monthly magazine targeted to Senior Business Executives, Line-of-Business Managers, Senior IT Executives, and IT Managers who are working together to drive agility and innovation throughout their companies to increase profi tability and to enhance competitive advantage.
While other high-level publications focus individually on the CIO, IT, or Line-of-Business Managers, BTI will deliver the “how-to” and “what works” information necessary for aligning and leveraging the eff orts of both groups of managers working together to achieve business objectives through improved innovation and agility.
Each issue will include articles and columns from some of the most respected authorities in the business and IT fi eld. Some examples of topics to be covered include:
• SOA-enabled business transformation• Improving business process effi ciencies• IT governance best practices• Implementing BPM for results• What Line-of-Business Managers need most from IT• How IT can be an integral part of any transformation process• Legacy systems transformation strategies• The adaptive enterprise• Care and framing of strategic innovation challenges• Innovating to achieve competitive advantage• Human resource transformation.
Whether it’s how to improve supply chain processes, integrate partners, understand the uses of Service-Oriented Architecture, better understand enterprise architecture, or deliver a new service to a customer segment, BTI is the source for business transformation and innovation.
EnterpriseArchitecture
as StrategyTransforming
Your Business to Achieve Agility
Managing IT as aBusiness
PASSINGFADBUSINESSSTRATEGY?
or a SubstantiveLong-Term
Transformation& Innovation:
PASSINGFADBUSINESSSTRATEGY?
EnterpriseArchitecture
as StrategyTransforming
Your Business to Achieve Agility
Managing IT as aBusiness
or a SubstantiveLong-Term
Transformation& Innovation:
Agile Compliance | Leveraging SOA to Increase Revenues
Subscribe to BTI at www.btijournal.com
LaunchingJanuary 2007!LaunchingJanuary 2007!
BTI Magazine Ad.indd 1 11/15/06 4:56:00 PM
E n t E r p r i s Ei n t E G r i t Y
B Y D a v i D m c G o v E r a n
6 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
this month, we reprint, with minor edits, my column on BPMS that
was published in the September 1999 issue of EAI Journal. Despite much progress, the message of that column remains relevant today to all aspects
of integration and to business transformation. Remember the days in which data was managed exclusively by applications? Each application owned the formats, operations, and I/O methods. Oh, the long nights we used to spend examining COBOL or FORTRAN code for data semantics just to write a meaningful new report program. Wonder why we didn’t just look up the information in the data dictionary, repository, or system catalog, or why the programmers didn’t just use a DBMS? For all of you who take DBMS concepts and facilities for granted, the answer is they didn’t exist! DBMS technology provides consistent, managed data change, the essence of business transaction processing. Its value to business integration and transformation is well-known, even if seldom acknowledged. Lessons can be learned from the DBMS story and a new opportunity seized in doing so. RDBMSs brought a true IT revolution, changing computing forever. When commercial RDBMSs were introduced, there were no standard ways of 1) organizing data, 2) accessing data interactively, 3) accessing data programmatically (despite CODASYL, proprietary approaches ruled!), or 4) remotely accessing data (files yes, data no). RDBMS availability made data sharing (across modules, applications, and even systems) possible and ultimately the norm. Of course, it took a while to get a standard language and even longer to get a non-proprietary API. The relational model made both possible: Physical data independence hides the dirty details of physical storage, logical data independence hides logical changes where desired, and location independence hides physical location. Without this encapsulation, distributed applications were impractical: It’s no accident that client/server and network computing’s predecessor (LAN-based computing) took off with RDBMSs. And without these, EAI (and ERP) could not be. The great new opportunity I mentioned? Well, today applications hold processes captive much as they once did data. There’s no standard process language (except BPEL) or API, and no process analogue of the RDBMS. So last year (1998), I suggested a new concept to several EAI vendors—the BPMS (Business Process Management System). A BPMS manages business processes independent of applications: Process information is easily shared, accessed, and managed. As data modeling tools are used to design database schemas, so process modeling tools could be used to design process schemas (improperly called “processes”). Like an RDBMS, a BPMS stores process schemas, process constraints, and inter-process relationships in its system catalog. A repository for process “runs” the BPMS analogue of RDBMS data.
Early commercial RDBMSs provided tremendous and immediate investment return by enhancing query, decision support, and report capabilities, as will the BPMS. And the decision support/analytic potential of a BPMS can take us far beyond querying the “status” of some business process, allowing physical performance parameters of a process schema to be related to business performance metrics. Even so, such passive BPMS uses ignore the real potential as active IT components. BPMSs will be more than process schema repositories, becoming the process “database of record,” and externalizing business function logic. The BPMS then both monitors and controls process flow much like an intelligent message router: After all, a business process is just a set of inter-connected business rules, a network of business events, activities, or functions. At the highest level of process abstraction, the BPMS controls the business logic between applications, business functions, or activities, permitting process modification without shutting down applications. Today’s workflow products can be considered a primitive BPMS technology, but lack key features. General process schemas, real-time performance, and transactional recovery features must be supported to obtain the real potential of BPMSs. That potential lies in process independence analogues of physical, logical, and location independence, which are necessary for business integration and transformation success. Like data schemas, process schemas (found today as application control or procedural logic) must support multiple descriptive levels or process abstraction hierarchies. Unfortunately, the procedural logic that implements multiple process levels is rarely separated in application code. Solve these problems, and BPMSs will enable changes to the physical implementation of business logic without impacting management’s business process understanding. More important, managers can then implement business process changes with minimal impact on or involvement from IT. Early BPMS technology existed in products such as HP ChangEngine, IBM MQWorkflow (now IBM WebSphere MQ Workflow), Vitria, and others. Still, analogues of SQL, database transactions, and relational API are needed to progress. And we need dynamic optimization of the location of process execution—whether externalized in a BPMS process engine or internally in the application. Although BPMS technology lacks the functional maturity or definition associated with RDBMSs, today’s products tangibly hint at the flexibility and economic benefits of the BPMS vision. IT and business drivers foretell increasingly rapid business process change. Without a BPMS as a key component of the business integration architecture, that demand won’t be met. And I hope you’ll agree that consistent, managed business process change is the very essence of enterprise integrity . . . and therefore of business transformation. bij
About the AuthorDavid McGoveran is president of Alternative Technologies. He has more than 25 years of experience with mission-critical applications and has authored numerous technical articles on application integration. Email: [email protected]; Website: www.alternativetech.com
t h i n k B p m s
BPM
BPMMM ost businesses have a
l i m i t e d , e x p l i c i t understanding of end-to-end business processes, and
if any understanding exists, it’s often tucked away within disparate groups across the organization. It’s rare to find an organization that has linked its scattered process competencies together into a comprehensive strategy. However, this is changing as Business Process Management (BPM) gains momentum. Gartner has created a six-phase BPM maturity model that involves understanding the six phases of BPM maturity and where your organization stands on addressing critical success factors defined in a BPM maturity framework.
The Six Phases of BPM Maturity: Overview The BPM maturity and adoption model provides guidance for how your organization can more easily navigate the challenges of becoming process-managed. Figure 1 identifies the six phases of BPM maturity. The journey toward a fully process-driven organization begins in Phase 0 with acknowledgment that some busi-ness improvement opportunities can’t be
addressed by conventional approaches. The need to seek fundamental opera-tional change results in Phase 1, becom-ing “process-aware.” As the organization becomes more process-aware, it enters Phase 2 when it begins automating spe-cific processes to gain better control.
Eventually, the boundaries of individual processes expand, and in Phase 3, the organization must integrate these pro-cesses with each other, as well as those of trading partners and customers. Competencies grow around managing the relationships between major busi-
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 7
BuSInESS • Withoutamap,thejourneytoBPMmaturitywillbedifficultand
frustrating.• TheBPMmaturitymodelisbasedonthebeliefthatsuperior
processmanagementleadstorealizingatrulyagilebusinessstructure.
TEChnOlOgy • Astheorganizationtranscendsthrougheachphaseofmaturity,the
achievementofitscriticalsuccessfactorsalsomustevolve.• TheBPMmaturityandadoptionmodelprovidesguidancefor
howyourorganizationcanmoreeasilynavigatethechallengesofbecomingprocess-managed.
H A v I N g A BPM M A T U r I T Y M O d E L I S I M P O r T A N T f O r L O N g - L A S T I N g
BPM S U C C E S S
Figure1:TheSixPhasesofBPMMaturitySource:Gartner
By Michael Melenovsky & Jim Sinur
ness processes and, by Phase 4, the expertise exists to dynamically link stra-tegic goals to process execution. This, ultimately, leads to the creation of an agile business structure (Phase 5)—the highest level of maturity. The curve embedded in the maturity model repre-sents the amount of effort, and subse-quent benefit that will accrue in each phase. As you approach the more advanced phases, the steepness of the curve shows that more work is required, but more return value is expected. This is a hallmark of maturity: Wisdom comes from investment, and wisdom begets increased benefit. The majority of organizations are in the earlier phases of BPM maturity. Although many organi-zations will be deep into learning the disciplines of Phase 2 by the end of 2006, few will have mastered the process auto-mation and control competencies. Therefore, the percentage of enterprises mastering any particular phase will be much smaller than the percentage expe-riencing or experimenting with the same phase. Further, mastery of the more advanced phases will remain elusive well beyond 2008. We set the bar high when we created this maturity model.
The BPM Maturity Model and Its Critical Success Factors The BPM maturity model is based on the belief that superior process man-agement leads to realizing a truly agile business structure. The competencies gained along the way to becoming agile create greater visibility into how the organization delivers value, innovates customer service, and gains operational
productivity and effectiveness. Each phase of maturity builds on the previ-ous phases, but also allows for initiatives that grow competencies for later phases to occur during earlier phases. The objective then becomes managing the “weakest link” when balancing the criti-cal success factors of organizational process management. In addition to the six phases of maturity, the other impor-tant dimension is the organizational factors that must be balanced within and between phases. Figure 2 shows six critical success factors that an organiza-tion must evolve during each phase as it becomes process-driven. As the organization transcends through each phase of maturity, the achievement of its critical success factors also must evolve. Leading organizations take a balanced approach to managing the six critical success factors. Managed together, they represent the framework from which BPM competencies are built. The six success factors are:
1. Strategic alignment: The continual tight linkage of organizational pri-orities and enterprise processes, enabling the achievement of busi-ness goals
2. Cultureandleadership: The collec-tive values and beliefs that shape process-related attitudes and behav-iors
3. People: The individuals and groups who continually enhance and apply their process-related expertise and knowledge
4. Governance: Relevant and transpar-ent accountability, decision-making
and reward processes to guide actions
5. Methods: The approaches and tech-niques that support and enable con-sistent process actions and outcomes
6. IT: The software, hardware, and information management systems that enable and support process activities.
Bottom Line Without a map, the journey to BPM maturity will be difficult and frustrat-ing. We’ve provided a starting point for organizations to map out their journey ahead of time and determine the proper number of rest stops along the way to the ultimate destination, which may or not be the last phase. We believe your competition will drive you far into this maturity curve. Gartner has more detailed information on each of the phases and the typical outcomes for each of the success factors on its busi-ness process improvement site. In early 2007, Gartner will be providing a self-evaluation tool. bij
About the Authors Michael Melenovsky is a research director with Gartner Research, where he provides a leadership role in business process management research, focusing on strategy, justification, organizational changes and best practices. He has almost 30 years of IT
industry experience, and has held several senior management positions throughout his career. As a senior vice president at Rockwell International, he led the start-up of customer services operations for the industrial automation group and participated in corporate strategic planning.Email: [email protected]: www.gartner.com
_________________________________
Jim Sinur is a vice president and distinguished analyst in Gartner Research. His research and areas of personal experience focus on business modeling, business process management technologies, rules-based systems, using legacy systems in e-business applications and
business activity monitoring. He is active in supporting the application integration and development areas of Gartner. In addition, he was critical in creating the first “Hype Cycle” at Gartner, which has become a hallmark of Gartner analysis along with the Magic Quadrant. He has been active in the Rules, Data and Computing Communities, helping shape direction based on practical experience. Email: [email protected]
8 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure2:BPMMaturityFrameworkSource:GartnerandBabsonCollegeProcessManagementResearchCenter(2006)
5S ervice-Oriented Architectures
(SOAs) and message-driven applications based on Web services
represent a fundamentally different approach to application development. As we discovered with the networks in our organizations, these applications no longer have easily defined boundaries. The reuse attributes of business and technical services means the components we’re building will be used to construct many different applications in many contexts, potentially quite different from those the original designers envisioned.
SOA Security Issues Securing SOAs and ensuring their correctness requires careful consider-ation of the implications of the values we derive from our SOA. A full treat-ment of all the ramifications and issues is beyond the scope of this article, but consider a few of the more significant ones:
• Unplanned reuse: Reuse of services introduces problems of data privacy, controlled access to authorized con-sumers and final disposition of data, particularly when composite applica-tions are used.
• New risk implications for message-based applications: There are a host of issues that aren’t usually considered for traditional application design that are relevant with message-oriented applications. Replay attacks, out-of-order command insertion and modifi-cation of state, for example, open up the potential for design time security flaws in our applications.
• Service contracts: Defining service contracts in support of loose coupling is only part of the control story. Managing change as service contracts evolve to adapt to the range of differ-ent consumer needs for identity, cre-dentials and many other policy changes is a significant issue for SOA, too.
From architecture through develop-ment, testing, deployment and opera-tional management, these and many other aspects of designing and imple-menting an SOA are unique and chal-lenging. The infrastructure we create to enable SOA should be considered by participants in the SOA development process, including:
• Architects (“Where can I offload and control services?”)
• Developers (“Who is taking care of policy implementation for me, includ-ing privacy and security?”)
• Operations and security staff (“What policy settings are implemented in the infrastructure that let me make adjust-ments without involving the develop-ment folks?”)
Ignoring security and quality in the development cycle exposes corporations to a multitude of risks that will further hinder effective, safe deployment of an SOA.
Keys to Success Multiple success factors apply to the various phases of an SOA and Web ser-vices lifecycle, but it boils down to a set
of five keys to avoid security, reliability and compliance issues:
• Simulating the production environ-ment in development
• Articulating policies for consumers and providers and making trade-offs regarding compatibility, security and throughput
• Creating a suite of test messages for both the service customer and the ser-vice provider
• Exercising each service consumer and provider separately to evaluate every policy and potential exception that may be encountered in production
• Verifying that the virtualization and configuration are cost-effective and scalable.
One of the most important steps in bulletproofing SOA and Web services is creating a development environment that effectively emulates the conditions and infrastructure that will support the appli-cation in its operation. A service that works well in a development environ-ment can reveal problems once it hits production, resulting in significant time delays and cost overruns. In a message-oriented architecture, the downstream impact created by consuming an existing service can be difficult to ascertain. A service several processing hops away may be overloaded by the additional transac-tion load a new consumer introduces. Developing the service in an effec-tive emulation of the production envi-ronment reduces the number of surprises when the service is deployed, reducing the time and cost needed to
1 0 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
B U L L E T P R O O F I N G Y O U R S O A
Five Keys for Secure SOA and Web Services
B Y B R I A N R O D D Y
Don’t let a trading partner’s failure disappoint
your customer.
©2006 Sterling Commerce, Inc. ALL RIGHTS RESERVED. Sterling Commerce and the Sterling Commerce logo are trademarks of Sterling Commerce, Inc. Sterling Commerce is an AT&T company. FORTUNE is a registered mark of Time Inc.
Assure flawless information hand-offs and make your systems collaborate the way 75% of the FORTUNE® 100 do.
If your company depends on partners outside your control, you should depend on Sterling Commerce. Only
Sterling Commerce Multi-Enterprise Collaboration (MEC) solutions allow you to optimize communities, pro-
cesses and technology. So you can leverage your current assets with configurable software and services
built on a services-oriented architecture, ready for implementation right now. You get visibility into your entire
value chain and increased control moving forward. With over 30,000 customers worldwide, we’re sure to have
a solution that pleases you…and your customers. Visit us at www.sterlingcommerce.com
C O M M U N I T Y E N A B L E M E N T / S U P P L Y C H A I N A P P L I C A T I O N S / P A Y M E N T A P P L I C A T I O N S / O N - D E M A N D S O L U T I O N S / B 2 B C O L L A B O R A T I O N
remedy those surprises. As a corpora-tion’s production environment is upgraded to leverage XML intermediar-ies (such as XML security gateways or XML routers), the development envi-ronment also should provide functional versions of those intermediaries. Supporting infrastructure such as Identity and Access Management (I&AM) systems must be simulated to allow validation of design choices as early as possible. A client needs to behave as expected when messages are received from the service. Will Secure Sockets Layer (SSL) be used? Are credentials or identities to be mapped? What’s the mapping mech-anism that executes the logic? What infrastructure components—certificate authorities, Security Assertion Markup Language (SAML) authorities, key dis-tribution centers—will be trusted? What message fields should be encrypted? What information content is private and what application, organization and geographic boundaries can it cross? The reuse features of deployed ser-vices have a serious implication in this context. Fully cataloguing and control-ling the set of services deployed can be challenging, although the application of governance controls and service reposi-tories help. Controlling the growing col-lection of service consumers may be much more challenging. What do those consumers do with the data? How do their transaction requests affect control of the application? Is the use of the busi-ness service in the context of this new consumer reasonable? Effective access control, authorization rule integration, auditing and reporting must be institut-ed to support confidence in the correct-ness of the application system. Much more than traditional application devel-opment, the reusable, granular nature of these new business services make these and many other decisions crucial. Once policies are articulated, it’s nec-essary to test them. Doing so requires creating positive and negative test mes-sages that put the policies, services and XML intermediaries under stress. To eliminate surprises, positive, negative and random variations of the test mes-sages must be sent to exercise the differ-ent policies. This is perhaps the simplest step as the catalogue of messages that need to be considered can easily be deter-mined by an experienced QA tester based on the service interface descriptions. Exercising the consumers and pro-viders must take place in the context of the simulated production environment
after initial unit testing is completed. Executing these tests in a cost-efficient manner is often challenging, but XML network intermediaries create effective policy enforcement and monitoring points. Fire the prepared test messages through an XML gateway and monitor the results. Tests may include:
• Validation of acceptable and rejected authentication methods
• Correct mapping of identities and translation of credentials
• Can bilateral handshakes be handled efficiently?
• Schema validation• Authorization (are trusted identities
granted correct access to services?)• Content-based routing—testing for
different routes and correct invocation of service choices
• Message transformation• Protocol mediation• Firing malicious content at the service
(What happens if there’s bad, mal-formed content in the XML?)
Once pair-wise testing of the services and their consumers has been complet-ed and the various issues resolved, it’s time to move onto validation of the application system. We may be con-structing a new application in which all services are being used for the first time. If so, all the loading, performance, fault handling, recovery and correctness cri-teria of the system must be evaluated. Over time, we’ll be constructing inter-linked or overlapping systems. The new application will begin to impact the throughput, reliability and (potentially) correctness of the existing application systems already deployed, where some set of shared services are being reused. The impact of the new application and service must be tested by carefully exer-cising message sets against the other interlinked applications. Finally, when deploying SOA and Web services, it’s essential that organiza-tions leverage existing infrastructure and technologies. Reference architectures for SOA call for XML intermediaries to address the security, reuse and service availability required to manage the risk of a distributed application system.
Meeting the Challenges One of the most significant chal-lenges we face as we deploy these new systems is buffering our developers from the constant change that the envi-ronment creates. It’s not feasible to have all of our application programmers
aware of all the sophisticated intricacies associated with privacy or security. XML standards continue to morph and most organizations can only hope to progressively integrate the new tech-nologies they need. XML network intermediaries provide this buffer by allowing policy-driven decisions to occur without recourse to constant pro-gramming. SOA and Web services can accommodate new or altered require-ments from consumers or providers without code changes. The presence of XML intermediaries raises requirements to ensure that they enhance the overall performance of the application system. These components must effectively operate at wire line speeds and provide supporting tech-niques such as caching and message processing optimizations to overcome latencies otherwise introduced by their presence. Use of these devices must enhance the manageability of the appli-cation system and support operational requirements such as monitoring and logging of activity. XML network intermediaries that support extensive service virtualization allow changes in the provider service contracts in a controlled way that doesn’t create service interruption for the ser-vice consumers. As services are built, a consistent, reliable quality infrastruc-ture to test services, clients and XML intermediaries is crucial to reducing risk, accelerating time to market and maximizing reuse of services. XML net-work intermediaries play an important role in managing the ever increasing complexity of these tasks.
Conclusion The keys to bulletproofing SOA tar-get elimination of unforeseen surprises. By following these outlined steps—from design to development to testing to deployment—SOA and Web services can become bulletproof, resulting in fewer surprises throughout the services lifecycle, a shorter services development cycle, and faster time to market. bij
About the AuthorBrian Roddy is vice president of engineering and co-founder of Reactivity. He is a frequent speaker on security at conferences such as RSA and ACSAC. He previously held positions as a senior scientist in the Advanced Technology Group at Apple Computer and as a researcher at AT&T Bell Laboratories. He received a master’s degree in Computer Science from the University of Wisconsin and a bachelor’s degree in Engineering from the University of Pennsylvania.Email: [email protected]: www.reactivity.com
1 � • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
1 4 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
in the book, On Death and
Dying, Elisabeth Kubler-Ross defined five stages to accepting one’s fate—Anger,
Denial, Bargaining, Depression, and Acceptance. We need something similar to characterize what people are going through when adopting, or not adopting, SOA. You’re an architect, happily humming along to a verse of Dire Straits’ “Brother in Arms,” and in walks your CIO. He sits down across from you, and with a smile eerily dragon-like because of its toothiness, he says, “Son, I’m sorry to tell you, but you have a terminal case of SOA. We expect a successful enterprisewide implementation in six months.” Well, you know it “ain’t gonna” happen, but you smile anyway and say, through clenched teeth, “OK, chief,” as you remember you still have 12 payments to go on those Ronco steak knives that will cut through tin cans. Now the clock starts ticking and you enter the stages: Dumbfounded, Rationalization, Euphoria, Depression, and Acceptance: Dumbfounded: “SOA? How the heck am I supposed to do this? I can hardly even spell SOA! Not only that, but I’d bet my Uncle Ned’s toupee that our CIO can’t spell SOA, either.” So, you stare out the window for exactly 38 minutes (the arbitrary amount of time it takes for brain cells to begin to atrophy when an idea refuses to make sense) and then decide you need a drink. Off to the bar. There, you find a boatload of IT people staring into space while guzzling Dewar’s and mumbling SOA under their breath. You order a drink and open your laptop to study. Rationalization: OK, so you’re figuring out SOA after the fourth Dewar’s. Sure, you can do this. Just build some services and put them out on the server and anyone can use them. Yeah, that will work—right? We don’t need to throw out all our old middleware. This might be just the excuse we need to bring in a whole new generation of middleware, starting with those ESB things. And business analysts to take the burden of defining the business processes. Yeah, this might work! So, you keep scanning, ignoring the little man in your head screaming that it can’t be that easy. Woe to he who drinks and reads product literature at the same time. That’s when you encounter the dreaded vendor hype-machine. Euphoria: The dictionary defines “Euphoria” as “a feeling of great happiness or well-being.” The little guy screaming in
your head defines it as—“sucker!” OK, so that’s a little harsh but you have to remember, you’re buying into the vendor hype-machine. SOA will let you get business people to design their own systems, they say. SOA requires no change in your approach. Buy our products and your SOA will build itself. Services are just the same as objects and components, so we’ve been doing it for years. We’re all about business transformation, so buy our widget library. You go floating on a cloud of this kind of hype and then … Depression: The cloud dissipates and you’re in freefall. The middleware you bought is working fine but no one can get the services to do what they’re supposed to do. Worse yet, you spent three weeks choosing an ESB, and now your team has sat around for another three weeks saying, “now what?” Oh, and don’t even get me started on processes. What are they, by the way? Are service processes or are processes services? Who owns these processes anyway?! After a three-month depression, you begin to see the light. It dawns on you that you (the architect) can’t do this alone. SOA is the responsibility of the business units as much as it is yours. You pull a competency center together. Acceptance: You decide to treat SOA as a discipline instead of a middleware exercise. You start from the business perspective and products come after. You train people to be service providers, to capture best practices, and to organize themselves with the right roles to manage and maintain processes. You track your failures and monitor your successes—to learn. SOA isn’t a technology innovation. It’s an opportunity to make systems more agile by mimicking business processes instead of machine code. But this works only if you go at it the right way. The good SOA architect buys middleware only after understanding how it will be used in specific scenarios. She takes measured steps to ensure each service is governed and the processes being used are under service-level agreements. She accepts that SOA is a long-term value proposition, not a short-term fix. So, there you have it. SOA stages to acceptance. They may be depressing but they’re helpful to depict what to avoid. The moral of the story is: SOA isn’t something you will just choose to do—it’s something that will happen to you. Approach it as a discipline and you may find that it won’t kill you. bij
About the AuthorDaryl Plummer is group vice president and chief Gartner Fellow. He manages the Emerging Trends and Technologies Segment of Gartner Research and Gartner’s Fellows Program Office. Email: [email protected]; Website: www.gartner.com
UnConvEntionaLWisDom o n D e a t h a n d D y i n g —s o a s t y l e
B Y D a r Y L p L U m m E r
S ince the beginning of the Internet revolution, IT has sought to open access to back-end systems and their
associated data. This is a challenge to existing legacy systems that respond slowly and may have been designed to support a smaller number of consum-ers. Many solutions solved this problem by opening up asynchronous access to the legacy system; others were archi-tected to be inherently asynchronous. Access to the data and business logic in these legacy systems is now being made available to portal-based applica-tions. These new applications place strict demands on the services that are exposing the back-end systems and their data, including:
• Subsecond response times• Synchronous behavior• Standards-based access.
With rich Internet applications employing techniques such as Asynchronous JavaScript and XML (AJAX), asynchronous data access from these legacy systems then becomes a necessary practice.
The Challenges The business challenge is to create a flexible, automated, larger business pro-cess that will encompass slow, packaged applications that have been commis-sioned to solve specific business prob-lems. Customers, employees, and partners should be able to interact with these systems over the Internet. The IT challenge is to expose pack-
aged applications (siloed, slow and cur-rent accessible only asynchronously) and allow access to them in a standards-based approach with minimal or no coding so business needs can be quickly addressed. Some of the packaged appli-cations haven’t yet been exposed; others have been exposed via a Messaging-Oriented Middleware (MOM) approach or via conversational Web services. Usually, this must be accomplished with limited resources and a plan to address maintenance costs. Asynchronous com-munications is a necessary evil for reducing system concurrency and work-ing with limited resources, threads, etc.
The ESB as a Solution Enterprise Service Buses (ESBs) have gained support within the IT and busi-ness communities as a way to imple-ment their integration and Service-Oriented Architecture (SOA) strategy. Business and IT require an intelligent service infrastructure. An ESB delivers it via a metadata-driven, no coding way to connect, transform, mediate, and translate messages in a heterogeneous, multi-platform, multi-vendor environment. An ESB provides the out-of-the-box protocol translations necessary for bridging different trans-ports and messaging paradigms, includ-ing synchronous-to-asynchronous request/reply bridging. The modern synchronous client operates over HTTP, while the tradi-tional asynchronous legacy systems are exposed via messaging-based systems such as WebSphere MQ, TIBCO’s
Rendezvous, Microsoft Message Queing (MSMQ), etc. Some of the modern asynchronous legacy systems have been exposed via Web services with call-backs. The correlation between the request and the callback is expected to be handled by the Web service con-sumer that makes the request. Accessing a legacy system that’s inherently exposed as a synchronous service is a no-brainer. It can get inter-esting if the protocols and message for-mats of the client and legacy system differ. An ESB can easily bridge this inconsistency. For example, a portal might send an XML over HTTP request to a legacy system that can be accessed via SOAP over HTTP. As shown in Figure 1, the ESB would translate the message and change the protocol to SOAP on the request and response. Let’s now explore how we can achieve synchronous-to-asynchronous bridging through an ESB for cases where the lega-cy system is exposed via a messaging sys-tem or via Web services with a callback.
Legacy Access Via Request/Reply Most messaging systems have a Java Messaging Service (JMS) interface to facilitate a request/reply architecture. Here, an ESB can be configured to ser-vice HTTP requests. The request pay-load is published to the inbound JMS queue for the messaging infrastructure. The reply would arrive on a JMS queue that the ESB can listen to. The ESB would correlate the message reply with the request and send the appropriate response to the blocking HTTP client.
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 1 5
BuSInESS • TheESBisapracticalchoiceforprovidingalooselycoupled,
transport-neutralservicewithfulllocationtransparency,tomakeaccesstolegacysystemsaslamdunk.
• Thebusinesschallengeistocreateaflexible,automated,largerbusinessprocessthatwillencompassslow,packagedapplicationsthathavebeencommissionedtosolvespecificbusinessproblems.
TEChnOlOgy • UsinganESB,youcanconfigureaservice(calledaproxyservice)
thatprocessesclientrequestsandaprocessingpipelinetoprocessthemessage.
• Mainframelegacysystemswereneverdesignedforaccessbyfastmodernclientsoveropenstandards.However,ESBsmakeiteasyforaccessbysynchronousclients.
ESB Providing Synchronous Access to Asynchronous Legacy SystemsBy Shiva Bhajekar & Ashish Krishna
What happens if the request sent by the client is in a different format from what the legacy system expects (see Figure 2)? Consider a user requesting a mortgage loan approval by filling in an online request form on a portal. The portal processes the form and sends a request to be processed by an applica-tion that’s running on a legacy system. Due to the design limitations of this application, it processes messages asyn-chronously; it reads off a pre-defined JMS request queue. Once the applica-tion finishes processing, the response is published to a pre-defined JMS response queue. The portal, however, can only send SOAP over HTTP in this case. Without an ESB, one would have to programmatically develop and deploy an application using an integration framework to process an incoming HTTP request, and then write an eXtensible Stylesheet Language Transformation (XSLT) or XQuery transformation to be applied to the request and response. Moreover, it’s the application’s responsibility to translate between HTTP headers and JMS head-ers. On the response side, this applica-tion will contain a listener that will then be used to extract the response from a pre-defined response queue, program-matically correlate the request and response, and send a transformed response to the client.
Using an ESB, you can configure a ser-vice (called a proxy service) that pro-cesses client requests and a processing pipeline to process the message. In a pipeline, there are steps to transform the incoming message or response and finally route it to a logical business ser-vice that’s a composite representing back-end JMS request and response queues. This configuration is then refer-enced by the ESB at run-time. The pro-tocol transformation from HTTP to JMS happens automatically. Furthermore, when the JMS request and response queues are configured as a composite business service, the ESB will automatically correlate request and replies in a scalable, clustered environ-ment. Figure 3 shows an example of such a message flow, called a pipeline. This simple, yet powerful, feature lets an ESB provide a converged approach to a scalable, dynamic syn-chronous-to-asynchronous request/reply bridging. However, there are cer-tain drawbacks: • There’s no uniform or consistent way
of providing addressing details such as destination Universal Resource Locator (URL) or address for sending reply.
• There’s no way to specify alternative destinations for status or errors, and it requires service implementation-spe-
cific details or pre-determined desti-nations.
• The implementation details are left to the application architects and developers.
Legacy System Exposed Via Web Service An ESB can be configured to bridge between synchronous HTTP clients on the front-end and Web services on the back-end that are asynchronous because the response is sent to a callback address that can be defined in several different ways. For example, it could be:
• A pre-defined URL• Passed as part of the payload (either as
a custom header or part of the message body)
• Passed via WS addressing.
WS addressing facilitates a stan-dards-based implementation using SOAP over synchronous (HTTP) or asynchronous (JMS) mechanisms with agile services that can help IT react to business needs. Due to the lack of trans-port restrictions on the addressing ele-ments, you can take advantage of a wider set of transports and messaging patterns. For example, you can config-ure a fault address to be an email address so someone can be notified of error conditions. Consider a case where a user fills out a form on a portal to seek a loan approv-al. The SOAP request is sent to the ESB. The legacy application is exposed through a Web service that allows syn-chronous access for premium customers and asynchronous access for the rest. In this case:
• The back-end legacy application is exposed through Web services using SOAP and HTTP.
• The Web service-enabled legacy appli-cation uses a callback mechanism to invoke another Web service to deliver the response once the application has finished processing (see Figure 4).
A proxy service can be configured using an ESB that processes client requests and a pipeline configured to process the message. In a pipeline, there are steps to transform the incoming message or response and include ser-vices such as dynamic logging and reporting. In addition, you can set up a content-based routing policy that will be used to determine, based on content, whether to route the message to a Web service, exposing the legacy application.
1 6 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure2:AsynchronousAccesstoLegacyApplicationUsingJMSRequest/Reply
Figure1:SynchronousAccesstoLegacyApplicationUsingSOAP/HTTP
Furthermore, a WS address is dynami-cally added so the back-end service issues a callback to the ESB. Figure 5 shows an example of such a pipeline. In this figure, we see an ESB configured as a content-based router.
Summary An ESB’s core capabilities are:
• Fully configurable, no coding hetero-geneous messaging backbone that sup-ports various messaging paradigms
such as synchronous-to-asynchronous bridging out-of-the-box
• Support for standards such as WS-, JMS, File Transfer Protocol (FTP), email, etc. for advanced transport-level protocol translations and service brokering
• Built-in SLA configuration, alerting, logging and reporting capabilities for operational convenience and integra-tion with enterprise-level monitoring solutions
• Metadata and configuration repository with real-time integrity checks and dependency analysis for ensuring cor-rectness of services and pipeline semantics
• Sophisticated out-of-the-box, fully configuration-driven approach to security, including WS security, Secure Sockets Layer (SSL), message-level encryption, digital signatures, authen-tication, authorizations, Security Assertion Markup Language (SAML), and identity propagation.
Mainframe legacy systems were never designed for access by fast modern cli-ents over open standards. However, the ESB characteristics described here make it easy for access by synchronous clients. The ESB is a practical choice for provid-ing a loosely coupled, transport-neutral service with full location transparency, to make access to legacy systems a slam dunk. bij
About the AuthorsShiva Bhajekar, principal systems engineer at BEA Systems, advises Fortune 500 companies in Southern California to define and implement their SOA strategy while evangelizing BEA’s solutions. Having been in customer-facing roles for more than 12 years, he previously delivered several mission-critical
solutions at Netscape Professional Services to companies such as S&P, Sony and Warner Music.Email: [email protected]: bea.com
___________________________________
Ashish Krishna is an engineering product manager for WebLogic Integration at BEA Systems. Previously, he was an SOA technology specialist in a customer-facing role. He has a diverse background in enterprise integration and software development, including legacy systems, EDI and ERP integration technologies.
Email: [email protected]
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 1 7
Figure4:AsynchronousAccesstoLegacyApplicationThroughWebServiceWithCallback
Figure5:ESBConfigurationandMessageFlowPipelineforAsynchronousAccesstoLegacyApplicationUsingWebServiceandWSAddressing
Figure3:ESBConfigurationandMessageFlowPipelineforAsynchronousAccesstoLegacyApplicationUsingJMSRequest/Reply
By Tony M. Brown
Many organizations are embracing Service-Oriented Architectures
(SOAs), drawn to the business benefits of improving business process visibility and flexibility. This leads to the break up of the traditional application architecture that, at the enterprise-level, means a dramatic increase in the number of inter-dependent entities in the IT infrastructure. A poorly managed SOA has the potential to lead to an enterprise infrastructure of such complexity that its benefits are immediately outweighed. This complexity is compounded only by the possibility that services may be reused across organizational boundaries and heterogeneous domains of ownership.
The Problem of Poor Governance SOA success is highly correlated with an organization’s ability to manage complexity. SOA governance is concerned with establishing policies, controls, and enforcement mechanisms within the SOA domain (i.e., within the activities and constructs associated with SOA) and across the implementation lifecycle, from design through deployment to change-of-use. Without it, organizations can expect:
• Services that cannot easily be reused • Lack of trust and confidence in services as enterprise assets• Security breaches that cannot easily be traced• Unpredictable performance.
Quite simply, deployment of post-pilot SOA without proper governance is not a viable solution for most organizations.
The Technology of Governance As the foundation of SOA governance is the ability to enforce and automate policies across the service lifecycle, there is a major role for software system mechanisms that enable the automation and enforcement of governance policies. Two of the main components of this system are:
• A registry, which acts as a central index of business services• A repository, for storing policies and other metadata
related to the governance of the services. However, by themselves, these components are not sufficient. The registry and repository must be fully interoperable with each other and other SOA assets, and they must form a comprehensive system that manages the entire SOA lifecycle.
webMethods Infravio Solution webMethods’ SOA solution provides integrated SOA governance during design-time, run-time, and change-time. It provides the registry, repository and run-time enforcement that are essential for standardizing and managing the leverage
Governance: The Key to SOA Successof SOA assets throughout the entire IT lifecycle by different “SOA stakeholders”; e.g., architects, developers, IT management, and business users. The solution makes it easy to locate, understand and trust available services, which maximizes service reuse and adoption, and allows policy and process visibility to all SOA stakeholders. The solution consists of two fully independent and comprehensive products, webMethods Infravio X-Registry and webMethods Infravio X-Broker. With support for industry standards and initiatives, such as SOA Link, these stand-alone products work together seamlessly as well as with
other standards-based SOA products. webMethods Infravio X-Registry allows stakeholders to:
• Catalog, publish, locate, demo, and approve services• Reuse services easily and efficiently• Create a system of record for SOA metadata—policies,
schema, performance criteria, and contracts• Interoperate with UDDI V2 and V3, JAX-R, and ebXML
standards• Manage the governance rules engine and policy manager• Store digital documents and related service definitions• Capture audit trail of all registry activities.
webMethods Infravio X-Broker provides run-time support for securing, routing, monitoring, and managing Web services between provider and consumer applications. X-Broker enforces the delivery terms specified in the Web Services Delivery Contract, including the processing requirements and instructions for four major categories: security, integration, operations, and business. When combined with the webMethods Infravio X-Registry, the X-Broker provides end-to-end governance of services from design-time through run-time and change-time.
Bottom Line Comprehensive governance is not an option for enterprise SOA; it is a necessary requirement. SOA governance requires more than a registry or a repository. It requires an integrated solution that provides support for all SOA stakeholders throughout the entire SOA lifecycle. webMethods Infravio X-Registry and X-Broker are independent but fully interoperable products that deliver comprehensive SOA governance capabilities. Together, they form a standards-based SOA platform that allows organizations to fully reap the business benefits of SOA. bij
webMethodsInfravioX-RegistryandX-BrokerareavailablefromwebMethods,Inc.,3877FairfaxRidgeRoad,Fairfax,VA22030.Voice:703-460-2500;Website:www.webmethods.com.
1 8 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Service-Oriented Architecture (SOA) promises increased ser-vice reuse, reduced integration expense, and agility. To reap
these benefits, any SOA initiative must occur in the context of an enterprise-wide architecture and under the control of an effective governance program. SOA governance means different things to different people. Determining the appropriate scope of SOA gover-nance is challenging. Other tough ques-tions include how to leverage existing governance practices and what IT lead-ers should be doing about SOA gover-nance. This article explores the challenges of governance and provides forward-thinking organizations with a governance framework for SOA.
Governance Hurdles SOA touches every aspect of the business, so there’s a need to impose some discipline over the lifecycle of the services in these areas:
• Scope: Many businesses struggle to define SOA governance because all sortsof things get dragged into the governance framework.
• Culturechange: The development, deployment, and operational manage-ment processes for SOA dramatically differ from other approaches and require different governance disci-plines. The proliferation of services brings together previously discon-nected departments and functions; SOA governance must account for that.
• Technology governance: SOA trans-
fers monolithic IT functions into reus-able, service-based, portable formats. This requires a new approach to tech-nology governance.
• Morerulesandpolicies: SOA requires more organizational discipline than previous development models. Relatively few of the many develop-ment rules and policies in most orga-nizations are automated or even enforced.
Governance Types IT and business bind to different types of governance at different levels, including:
• Enterprisegovernance plays a role in the alignment between IT and busi-ness.
• ITgovernance addresses IT principle, architecture, IT infrastructure, busi-ness needs, and IT investment from the perspective of what decisions need to be made, who will make them, and how compliance will be monitored.
• Architecturegovernance is the prac-tice and process to ensure architectural integrity at an enterprisewide level; it encompasses systems design and deployment.
• Operational management gover-nance involves managing the run-time environment of all the IT systems, applications, infrastructure, and net-work.
• Others such as enterprise data and security.
Minimum requirements for any type of governance are:
• Discipline: All involved parties will commit to adhere to established pro-cedures, processes, and authority structures.
• Transparency: All actions implement-ed and their decision support will be available for inspection by authorized parties.
• Independence: All processes, deci-sion-making, and mechanisms used will minimize or avoid conflicts of interest.
• Accountability: Identifiable groups (e.g., governance boards) who take actions or make decisions will be accountable.
IT Governance lT governance should be driven from enterprise governance to ensure the organization’s IT sustains and extends its objectives. IT governance is the responsibility of the board of directors and executive management. In regard to IT principles, architecture, infrastruc-ture, investments, and business needs, questions that must be addressed include:
• What decisions must be made to ensure effective use of IT?
• Who should make decisions or con-tribute to them?
• How will decisions be made and mon-itored?
Many enterprises have created dis-parate IT governance mechanisms. These silos result from governance by default: introducing mechanisms, one at a time, to address a particular need.
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 1 9
SOA Governance FrameworkBy Ramy Aba By Ramy Abaas
Patching up problems as they arise lim-its opportunities for strategic impact from IT.
Architecture Governance Architecture governance is the prac-tice and orientation by which enterprise architectures and other architectures are managed and controlled; it encompasses:
• Controls over the creation and moni-toring of all architectural components and activities
• Compliance with internal and exter-nal standards and regulatory obliga-tions
• Processes that support effective man-agement within agreed parameters
• Accountability to a clearly identified stakeholder community.
Architecture governance is an approach, a series of processes, a cul-tural orientation, and a set of owned responsibilities that ensure the integrity and effectiveness of the organization’s architectures. The focus is on the design and deployment time governance and the processes around them as well as system reuse and commonality across different business units.
Operational Management The scope of operational manage-ment is managing the run-time envi-ronment of the deployed systems, applications, and their infrastructure to meet requirements. Since most systems are stand-alone, disconnected software systems that serve a business unit or a department, the only shared services may be the infrastructure services. Operational management goals involve reducing the cost of IT systems man-agement by efficient system operation, and integrating management of various IT resources. Most organizations haven’t implemented Service Level Agreements (SLAs) for operational management except in the area of sys-tem availability.
SOA Governance An SOA governance framework is a combination of the SOA organizational structure, governance processes, interoperability framework, and policies that govern the development, deploy-ment and operational management of the SOA. Each guiding principle for SOA governance should be defined with a rationale explaining the business rea-sons and implications. Architecture governance is the prac-
tice and orientation by which SOA enterprise architectures and other architectures are managed and con-trolled. Central governance is opti-mized for the enterprise, while distributed governance is optimized for distributed teams. To ensure that control is effective, you need the cor-rect organizational structures, which should include a global governance board, local governance board, design authorities and working parties. Figure 1 shows a view of the SOA architecture governance framework. Any IT organization also needs gov-ernance processes that provide a control system. Depending on the size of the organization, these processes should be implemented at the appropriate level matching the size—from individuals to teams to departments or even larger. Figure 2 lists the types of processes essential for successful SOA adoption. Most organizations have some or most of these in place, but SOA typically requires realigning and redefining the existing process. A key business objective of SOA ini-tiatives is to provide client-centric, joined-up business services to clients, which often requires an organization to be presented as a seamless flow of infor-mation across individual departments. An Interoperability Framework (IF) is essential to support the flow of informa-tion and to improve the coherence of information systems maintained by
individual departments or business domains. The IF defines a collection of specifications aimed at facilitating the interoperability of the different systems and services. By bringing together the relevant specifications under an overall frame-work, IT management and developers can have a single point of reference when there’s a need to identify the required interoperability specifications. By adopting these specifications, system designers can ensure interoperability between systems while enjoying the flexibility to select different hardware and systems and application software to implement solutions. In addition, the IF promotes and fosters the adoption of XML to enable the exchange of data between applications. The development of an IF is a long-term, ongoing strategy that must be continually reviewed and updated. Given the emergence of new business require-ments and the pace of technological advancement, there are likely to be fre-quent changes to the specifications. Existing systems must conform to the IF only when there’s a new require-ment, and only in respect to changes that specifically relate to external inter-faces. Migration to the IF must be con-sidered when a major functional change is being performed. Connection or changes to existing systems are required to conform to the IF only when it’s financially and functionally
� 0 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure1:SOAArchitectureGovernanceFramework–Organizational
prudent to introduce compliance with the IF. A major area where the IF is often applied is to facilitate interaction of two information systems. To enable two information systems to interoperate, they must be implemented based on a mutually agreed upon set of specifica-tions. The IF helps the two parties work out these specifications; it covers:
• A set of technical standards and data standards that help define the interface across different systems
• Guidelines for project teams to work out some of the business-oriented specifications where it’s feasible
• Other standards documents that define infrastructure architecture, conven-tions and procedures
• Technical standards addressing appli-cation integration, security, and infor-mation access.
These standards may already exist, but will need to be re-defined to fit the new SOA paradigm and be published as part of the IF.
Data Standards The data standards are most impor-tant because they cover the Common Schemas. The Common Schemas define the information model of data elements that are often used in the applications; they serve as reusable components for composing project-defined data specifications. To help departments work out their information exchange specifications (project-defined schemas) more effec-tively, an XML Schema Design and Management Guide should be devel-oped and published. The guide should provide a business information model-ing methodology to help departments model business documents and to trans-late information models into XML. The guide also should provide a framework for the development and use of Common Schemas. This guide should be pub-lished as part of the IF.
Infrastructure Architecture Infrastructure architecture, conven-tions and procedures specifications supplement the technical standards and data standards to facilitate interop-erability. The infrastructure architec-ture specifications include the network architecture, which describes the over-all network architecture. It defines the organization and the relationship of the IT infrastructure components.
These may include departmental net-works, common shared services, and the backbone network. Most organiza-tions have some form of infrastructure architecture that needs to be organized in the context of the IF. The only con-cept that may be new is common shared services.
Policies To govern the lifecycle of services, SOA governance uses a policy-based approach. The policy represents some constraint or condition on the use, deployment, or description of an owned entity as defined by any partici-pant. Policies provide a framework of
control and flexibility. Figure 3 lists different policies that govern the life-cycle of services. Design-time and run-time policies are associated with business services in the registry. Deploy-time policies are mostly associated with standards com-pliance and the service promotion approval process. Policies typically rep-resent non-functional requirements such as a certain level of performance, scalability, reliability, security or com-pliance with standards. They also may represent service configuration. There are three types of policies:
• Configuration and description poli-
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • � 1
*For seven years we have fulfilled customer needs with our powerful high-performance Tamino XML Server. Welcome to the club, IBM.
>> www.softwareag.com/Tamino
Dear IBM,Congratulations onyour first native XML database.We know this business inside out, so: Welcome to the club!Kind regards,
Software AG
� � • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
cies describe and configure certain non-functional features of specific SOA elements. For example, WS-Security and WS-Reliable Messaging policies describe and configure low-level security and reliability settings.
• Compliance policies are simple tags that mark either existing or desired compliance to specifications or stan-dards such as compliance to WS-I policy or Web Services Description Language (WSDL) specification.
• Constraint policies represent (typically non-functional) constraints or agree-ments that need to be fulfilled, such as SLA.
To manage these policies, you need to select a policy management tool that can provide policy management, asso-ciation, validation, and compliance and reporting capabilities. Policy management is used mostly by architects who define and maintain corporate policies. Basic policy opera-tions that should be addressed include:
• Assertion management, which is the ability to Create, Update, and Delete (CRUD) assertions
• Policy management, which is the ability to CRUD policies as a set of assertions
• Policy and assertion storage, which is storage of policies in a relational data-base
• Federation-ready policy access, which involves policy exposure as a standard Representational State Transfer (REST) resource using a WS-Policy-compliant document
• Open integration Application Program Interface (API), which is the ability to integrate with third-party applications via the standard HTTP REST API
• An open and standards-based inter-face for integration with various IT components that provide policy defi-nition and enforcement capabilities
• Support processes such as notifica-tion and subscription and approval workflow.
Policies are associated with their sub-jects (often a business service) in an SOA catalog. Policies are published to the reg-istry in the same way as business services or XML schemas. Registry policy pub-lishing is the ability to publish policies to a standard Universal Description, Discovery and Integration (UDDI) V3 registry or ebXML using WS-Policy Attachment standard. Standards-based policy association with registry entities involves the ability to associate services
(and other SOA components published in a UDDI V3 registry or ebXML) with published policies in a standard way. Policy validation is performed by specialized SOA services. It should pro-vide out-of-the-box support for:
• WS-I basic profile 1.1
• Syntactic validity, which is the ability to check syntactic validity of XML schema and WSDL documents
• Document integrity, which is the abil-ity to check references inside standard SOA description documents
• Registry integrity, which is the ability to check the integrity and compliance
Figure2:SOAInteroperabilityFramework(SOAIF)
CATEgORy
Business
Architecture
PROCESS
Service identification and prioritization process
Deviation fallback process
Review and approval process
Deviation and appeals process
Vitality process
Communication process
SCOPE
Defines a structured approach to identify, prioritize, and model business processes and services.
Provides formal definition of the business goals and key performance indicators that can be delivered by the architecture and implementation.
Business process deviation: No one can preview each and every possibility that can happen in an enterprise. Therefore, there must be rules for deviation that are set up and agreed to.
Ad hoc business process change: Ensure that the concrete SOA solution architecture has to incorporate entry points that enable certain users or processes to bypass the normal, formalized processes and process deviation. In a way, this gives another degree of flexibility for ad hoc business process changes.
Defines a structured approach to review and approve changes to the existing SOA and to make decisions in accordance with the governance guidelines.
Formal design and service evaluation reviews are key control points of SOA development for the installed governance units.
Provides means to appeal architectural decisions.
Allows deviation to the SOA architecture to meet unique business needs.
Ensures that the SOA is maintained and communicated as new services are incorporated into the architecture.
Variances to the architecture are documented and communicated.
Ensures that the SOA is available to all who need access.
Promotes the understanding of the importance of the SOA.
of UDDI or ebXML registry entities. Support also should be provided for an extensible policy, which is the ability to define custom policies using XQuery, XPath and Schematron XML assertion/query languages; registry integration, which is the ability to enforce policies from a UDDI V3 or ebXML registry console; and an open integration API, which may be the HTTP REST API for easy integration with other SOA prod-ucts and tools (e.g., Eclipse and Microsoft .NET). In terms of policy compliance and reporting, the tool should provide standards support. Service operating rules and policies should be imple-mented using publicly adopted stan-
dards such as WS-Security and WS-Reliable Messaging. It also should offer integrated lifecycle reporting. Registry users should be able to instantly open reports on service-related information, such as activity reports, violation of policies, and fail-ure of performance metrics.
Tools There are several SOA governance tools available with varying functionality. Most of the tools are based on a registry or repository and focus on design, deployment, and some aspects of run-time governance. There’s a need to com-bine them with the SOA management tools. You should look closely at the inte-gration between some of these tools if
you need to combine two tools to pro-vide end-to-end governance of services.
Conclusion SOA governance shouldn’t be built from scratch; it should be built by lever-aging existing governance practices. Although there are numerous gover-nance practices in the enterprise with different scope and focus, some can be re-defined, re-aligned, and leveraged to fit the new SOA governance paradigm. In planning for SOA governance, follow these steps:
1. Define the SOA governance frame-work.
2. Identify the existing governance practices and create gap analysis.
3. Re-define and re-align the existing governance practices to fit in the new SOA governance framework.
4. Based on the gap analysis results, create the rest of the SOA gover-nance framework components.
5. Select an SOA governance tool to enforce policies.
To achieve the promised value of SOA, the governance of the lifecycle of the services is extremely important. With a well-thought-out SOA gover-nance framework, SOA can solve many IT and business problems, but without it, the enterprise may face one enigma after another. bij
ReferencesPeter Weill, Jeanne W. Ross, “IT Governance,” 2004Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah, “Service Oriented Architecture (SOA) Compass,” 2006Mike Stevens, Scott W. Ambler, James Linn, Vikas Sharan, Elias K. Jo, James McGovern, “A Practical Guide to Enterprise Architecture,” 2004
About the AuthorRamy Abaas is a Global Strategy architect focusing on SOA, working for HP and helping GM, a leading global technology services company. He has more than 22 years of experience designing and developing IT systems for the Big-Five and Big-Three organizations. Email: [email protected]: www.hp.com
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • � 3
Figure3:SOAGovernanceandthePolicies
BuSInESS • SOApromisesenterprisesincreasedservicereuse,reduced
integrationexpenseandagility.• ToreapthebenefitsofSOA,anySOAinitiativehastobeundertaken
withaneffectivegovernanceprogram.
TEChnOlOgy • SOAgovernanceshouldn’tbebuiltfromscratch;insteaditshould
bebuiltbyleveragingexistinggovernancepractices.• Existinggovernancepracticeswilllikelyneedtoberedefinedtofit
thenewSOAparadigm.
� 4 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
sOA and wearable
computing? While a bit of a leap, this has me thinking … I mean, we have
the technology to place a small screen on my glasses, perhaps put a keyboard on my arm and connect it all through a satellite or cellular network. There are applications for this kind of technology today, including outfitting war fighters with complete information systems strapped to their bodies for use in combat. I mean, it can’t be much more expensive than the Diesel jeans I just purchased. Also, you have to love a technology where you can check your stocks, email, update your blog, and fire a round at somebody, all while running from building to building in some far-off land. At the essence of this is the notion of ubiquitous computing. Or, as Wikipedia defines it:
“Ubiquitous computing (ubicomp) integrates computation into the environment, rather than having computers, which are distinct objects. Other terms for ubiquitous computing include pervasive computing, calm technology, things that think and everyware. Promoters of this idea hope that embedding computation into the environment and everyday objects would enable people to interact with information-processing devices more naturally and casually than they currently do, and in whatever location or circumstance they find themselves.”
You have to admit this day is quickly coming, if it’s not already upon us, including cell phones that are now really small PCs, microwaves that can set their own time and calculate the cooking time for three potatoes, and information systems in the cars we drive that not only tell us when the oil needs changing, but schedules the appointment at the dealer, and calls somebody with your location to remove you from the wreckage when your airbag deploys. Considering the notion of ubiquitous computing, the larger question is the paradigm for communications in and between all these different devices that no longer look like traditional computers. I’m asserting that the basic principles behind SOA are the most applicable here. If you consider all these new devices as a collection of services and abstracted data, then the level of service use between them will be the next logical step. Considering this architecture, we simply deal with each device as a system unto itself with a physical data structure, abstracted data, services, composite services, and perhaps
U b i q u i t o u s C o m p u t i n g a n d s o a
B Y D a v i D s . L i n t H i C U mt H E n E x tW av E
some processes as well (see Figure 1). From there the services existing in the device are available to other devices, computer systems, or most important, to an orchestration or process layer where the interaction with all these devices and computer systems can be defined in terms of business solutions.
Thus, an inventory system showing the lack of a specific product can reach out and invoke a service on the logistics system to figure out how to get that product back in the warehouse. Then, the logistics system can schedule a pick up by invoking services inside the computer systems of the company’s fleet of trucks. In turn, you can track the progress of the pick up, and estimate to the customers when the product will be back in stock, and thus when you can ship, bill, and when the money will be reportable as income to the accounting system. You get the idea, including all computing power in your SOA to make your architecture that much more valuable. This isn’t science fiction; this is doable today. Companies just need to step up and learn how to leverage all the traditional and non-traditional computing power that’s already at their fingertips. bij
About the AuthorDave is the CEO of the Linthicum Group, LLC, a consulting organization dedicated to excellence in SOA product development, implementation, and strategy. He’s formally the CEO of BRIDGEWERX and the former CTO of Mercator. He has authored or co-authored 10 books, including David Linthicum’s Guide to Client/Server and Intranet Development, and Enterprise Application Integration released in 1999. His latest book, Next Generation Application Integration, was just released and is already a best-seller.Email: [email protected]
Figure1:SOAMetaModel
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.netTHE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net
SOA — Plan It: The SOA Strategic Services Blueprint page 4by Eric Roch
SOA — Build It: Creating Reusable Service Patterns page 5by Beth Gold-Bernstein and Brenda Michelson
SOA — Manage It: The Increasing Need for SOA Governance page 6by David A. Kelly
Buyer’s Guide starts on page 8
Buyer’s Guide
Buyer’s Guide starts on page 8
A Special Focus on SOA
Ready to move to SOA? ebizQ offers a complimentary training assessment for your organization! Go to http://www.ebizq.net/soaneeds
ebizqInsiderWinter06.qxd 11/8/06 5:49 PM Page 1
This Winter, the ebizQ Buyer’s Guide, is all about SOA!Welcome to the Winter 2007 edition of the ebizQ Buyer’sGuide, published once again as a special supplement tothe Business Integration Journal. Check out new partici-pating companies on page 11-12 or see them online athttp://www.ebizq.net/vendors/, or better yet, do both.
In this issue, we highlight only some of the exciting ideasthat appear in our SOA in Action Resource Center — your premier online destina-tion for pragmatic and actionable information on SOA solutions. The resourcecenter includes articles, blogs, podcasts, webinars, analyst reports and polls onplanning, building and managing SOA solutions. Even after our SOA in Actionvirtual conference, this dedicated website provides the SOA information you needmost. And, check out the back page to see if ebizQ can meet your company’s SOAtraining needs.
Plan it, Build it, Manage it — Eric Roch explains on page 4 how to develop yourplan for SOA, which includes his recommendations to organize an SOA steeringcommittee to develop a strategic services blueprint for SOA. He joins ebizQ’s ownBeth Gold-Bernstein and Brenda Michelson of Elemental Links, who have co-writ-ten a piece on the planning stage of SOA development, highlighting the need tocreate reusable patterns for SOA. ebizQ analyst David Kelly also contributes a pieceon SOA Governance, focusing on the importance of seeking the right kinds of toolsand technologies to support you along every step of your SOA journey.
Log onto http://www.SOAinAction.com to get more ideas and analysis like this,and I’d love to hear your feedback. Please email me at [email protected]
Les Yeamans, Publisher, ebizQ
Les Yeamans: Publisher
www.ebizQ.netLes Yeamans,President and PublisherRick Frey, Vice President and CFO
Analyst ServicesBeth Gold-Bernstein, Vice President, Strategic ServicesDavid Kelly, Analyst
EditorialElizabeth Book, Editor-in-Chief
OperationsJayaprakash Kannoth, Programmer AnalystJim Kutter, Internet Operations Consultant
ProductionMichele Thompson, Art DirectorRicki Pappo, Designer
Sales and MarketingLisa DiBiasi, Director of SalesPeter Damon, Director of Business DevelopmentEly Rosenstock, Director of MarketingGian Trotta, New Product Manager
ebizQ271 North Avenue, Suite 1210New Rochelle, NY 10801Phone: (914) 253-0850Fax: (914) 253-0855This publication is free for qualified business and technologyprofessionals and has no resale value. For a free subscription tothe ebizQ Buyer’s Guide, to download the current issue or forarchived issues, please visit www.ebizQ.net/insider.
All content printed in this issue is the sole property of ebizQ orhas been printed with the express written consent of its owner.ebizQ, expoQ, Integration Insider and ebizQ Buyer’s Guide arebrands of IT Quadrant, Copyright 2006. All rights reserved.Reproduction in whole or in part is prohibited. For reprint per-missions, please contact, [email protected].
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 2
Pu
bli
sh
er’
s N
ote
:
ebizqInsiderWinter06.qxd 11/8/06 5:41 PM Page 2
Company: Managed Methods
Product: JaxView
Address: 4853 Dakota Blvd.Boulder CO, 80304USA
Phone: (720) 222-2694
Web Site:www.managedmethods.com
Product Description: JaxView from Managed Methods is an SOA management and monitoring productthat provides a variety of tools for managing and governing Web services throughout the enterprise. As aJ2EE application that runs on Tomcat, JaxView is lightweight and can persist information to either a data-base in a distributed fashion for large load environments with thousands of Web services or the file systemfor small to medium deployments.The product comes with a console that enables users to centrally manageall installations of the tool. Through the console, administrators can configure monitoring and security poli-cies, read policies from the registry, configure alerts and events, and create and generate live or scheduledreports.The same instance of JaxView can be deployed for management purposes in a variety of ways:• Lightweight agents can be installed on the Web service containers that forward messages to the
JaxView server which provides monitoring and management.• As a gateway that virtualizes the services and provides authentication and governance capabilities.• As a network sniffer that accesses messages to a client without being intrusive. The auto-discovery
capabilities of JaxView discover the Web services and monitors them.• Through a JMS interface to monitor and govern requests from a message broker, or enterprise serv-
ice bus (ESB).
Focus: Because of its flexibility, JaxView is currently being used by companies of all sizes, from Global 50down to mid-sized organizations. The product has horizontal appeal to any organization that is using Webservices and needs to manage them. Among the industries that have leveraged JaxView are financial serv-ices, healthcare, retail and software manufacturing.
Strengths:• Lightweight. The light footprint enables JaxView to be installed quickly and easily into a user’s existing
system management environment.The typical user is an architect or operations-oriented IT individual.• Flexibility. The variety of configurations and ability to run multiple installations of JaxView and manage
them centrally make this product extremely adaptable to further Web services development.• Value. JaxView provides significant functionality at a competitive cost. This increases the return on
investment (ROI).• Ease of use. JaxView is shipped with the Tomcat application server, making it easy to install and start
using. The product supports all major platforms, from Unix to Linux, all Windows platforms, and Mac OS X.
Short-List Analysis: Managed Methods’ Web services management product is a compelling offer fororganizations moving to SOA.The lightweight nature of JaxView, its portability and flexibility, combined withthe value, make it a compelling purchase for companies wanting to manage and govern their Web services.The product is best suited for IT operations or IT architects, rather than business analysts. JaxView’s abilityto easily integrate with existing enterprise systems management consoles adds to the product’s flexibility.And, the ability to download and purchase the product directly from Managed Methods’ Web site makes iteasy to put this agile tool directly into the hands of the system administrators. JaxView can be purchased for$3000/cpu of the application server hosting the Web service.
Executive Summary: Managed Methods’ JaxView provides a flexibleapproach to Web services management. The product is designed tomeet the needs of small and large organizations that are moving to serv-ice-oriented architectures and are beginning to install Web services.JaxView is a lightweight Web services management product that pro-vides fault, performance, and SLA management and monitoring as wellas governance and security of all of the Web services running in theenterprise. The product can be downloaded from Managed Methods’Web site and installed in one of four ways to maximize flexibility. JaxVieweasily integrates with existing enterprise software management solu-tions to provide systems administrators and operations managers with acentralized console for monitoring and managing their distributed Webservices. Companies that are using Web services should considerJaxView’s flexible, affordable alternative to more costly Web servicemanagement tools.
Product Snapshot
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 3
Managed Methods’ JaxView
ebizqInsiderWinter06.qxd 11/8/06 5:41 PM Page 3
The SOA SteeringCommittee
To support building and planningan effective SOA, you need a busi-ness and IT team with a cross-func-tional view of the organization.However, most IT organizationalstructures are actually a barrier toSOA success. IT organizations aretypically silos with a manager andstaff assigned to support functionalbusiness groups. These silos oftenalso apply to systems — e.g., theHR IT team will support the HR func-tional department and the People-Soft application. So, when an ITfunctional group creates a service, itgenerally applies to their siloed viewof systems. Or, given this limitedview, they don't create functionalityas a service, but bury the functionali-ty in the siloed application with nointerface at all.
To overcome organizational barri-ers, form a cross-functional SOASteering Committee composed ofthe SOA sponsor, a lead architectfrom each functional-applicationsystem and an enterprise architect.The figure one diagrams the cross-functional structure of the SOASteering Committee.
The SOA Steering Committeealso supports the SOA CompetencyCenter. The SOA SteeringCommittee helps to create andapprove the standards and gover-nance policies to be used by theCompetency Center. By using across-functional committee of
PLAN your SOA
The SOA Strategic Services BlueprintBy Eric Roch
Strategic IT planning is critical fora successful Service-Oriented Archi-tecture (SOA) transformation. To getvalue from SOA, the effort must bebusiness-focused.Yet many IT shopshave historically done a poor job ofaligning the IT strategy and portfoliowith the business.
From a business perspective, wethink of SOA benefits in terms ofbusiness process agility or the abilityto create business processes fromcomponent services. But we alsohave to think about SOA in terms ofIT strategic alignment. Are wefocused on building services with themost benefits? Will our new servicescreate flexibility for the most strategicbusiness processes?
Consider that IT has traditionallyspent a great deal of time deployingcookie-cutter “ERP style” projects orsupporting monolithic legacy sys-tems. An ERP deployment best prac-tice unfortunately forces a change tothe business process itself to sup-port the package out-of-the-box. Weresist changes to legacy systemsbecause they are expensive and brit-tle. But now we are required to thinkdifferently. Business processesburied in monolithic systemsneed to be exposed as servic-es that can be reused by manybusiness processes.With SOA,it is now possible to consider ITbusiness alignment on aprocess-by-process basisautomating the activities thatsupport the business strategyin an optimal way.
But to achieve SOA busi-ness alignment, we need toplan the transformation over time.We need to create an SOARoadmap (projects over time) and aStrategic Services Blueprint (thefuture business services catalog)that will serve as a guide for IT trans-formation.
respected IT leaders to establishstandards, processes and the SOARoadmap, the organization canmanage the dramatic changes nec-essary for the SOA transformation.
The Strategic ServicesBlueprint
The SOA Steering Committeeand business leaders should consid-er candidate services by decompos-ing business functions keeping inmind the cross-functional needs(reuse potential) for each candidate.Service decomposition looks at theenterprise as a whole and seeks todefine the core services needed torun the company — the future-stateservices catalog. This presents SOAat a high-level strategic view.
Service decomposition requirestop-down and bottom-up analysis ofbusiness domains (functional areas).The top-down approach analyzesbusiness domains and decomposesthese domains into businessprocesses, sub-processes and usecases. This method presents servic-es in the context of the businessdomain, which creates clear servicescategories and helps to determineservice granularity by considering
cross-functionalreuse opportuni-ties.
By decomposingthe key functionalareas, one can cre-ate graphical repre-sentation of theservice catalog asin figure 2. Eachfunctional businessdomain is decom-
posed to identify core business serv-ices. These business services areadded to the model to represent abusiness view of the services cate-gorized by functional area. At thislevel, the services are easy to under-stand from business and technical
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 4
Figure 1
[CONTINUED ON PAGE 14]
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 4
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 5
By Beth Gold-Bernstein and Brenda Michelson
It seems the virtues of SOA arefinally beginning to pervade the cor-porate consciousness. While archi-tects have considered it a best prac-tice for decades, business managersare beginning to catch onto the factthat SOA may be their best ticket tobusiness agility, and they’re startingto invest.
According to a recent ebizQ onlinesurvey of over 300 members from 21industries, increasing business agilityis the number one reason for SOAadoption. In fact, the basic tenet ofSOA is agility. The goal of SOAdesign is to minimize impact ofchange.
However, while it is fairly straight-forward to teach programmers howto write or call a Web service inter-face, it is far more difficult to teachthem how to create loosely coupledreusable services that can easily bechanged. This is truly a new pro-gramming paradigm.
This article is based on a servicedesign method that helps businessanalysts, architects and developersdesign services optimized for agilityand reuse. Part of this method pro-vides a framework for identifyingservice characteristics and patternsthat can used to create reusableservices.
Types of ServicesA service is a software compo-
nent or module that can be combinedwith other services to create a busi-ness solution or application. Types ofservices include:
• Process-oriented services.These are business processesthat have multiple steps but fulfill asingle business purpose, such asopening an account, or placing anorder.
• Function-oriented services.This includes both business and
system functions. Examples of abusiness function include a soft-ware module that calculates amortgage, or performs a creditcheck. Examples of system func-tions include error handling andsecurity authentication.
• Data-oriented services. Thereare a myriad of data-oriented serv-ices required to maintain theintegrity of distributed data acrossthe architecture. These includeaccessing distributed data andpresenting a single view, datamapping and transformation,maintaining data quality and in-tegrity and maintaining metadata.
A single process can include all ofthese types of services. But it is use-ful to classify the type of servicebecause different types of servicesinherently have different characteris-tics, including behavior patterns andcommunication style.
Levels of GranularityA service can be comprised of
one or more services. Getting thelevel of granularity right is the great-est factor in enabling reuse. To aiddevelopers in defining the right levelof granularity for the services, wehave defined three levels:
• Business Services represent thecoarsest level of granularity. Abusiness service performs a logi-cal business function or process,such as opening a customeraccount.
• Intermediary Services providelocation, semantic, and technolo-gy independence between serv-ice consumers, business servicesand provider services. For exam-ple, a service that performs thedistributed query and aggregatesthe data into a single view. Manyof the system function orientedservices, including integrationservices, can be characterized asintermediary services.
• Provider Services are the finestlevel of granularity. Provider serv-ices map to application level inter-faces. For example, if a businessservice or process includes func-tions from several different backend systems, the functionality ineach of these systems would be aprovider level service. Examplesinclude retrieving a customerrecord or doing a mortgage calcu-lation.
When levels of granularity aredefined for different types of servic-es, patterns begin to emerge. Forexample, data-oriented providerservices will probably need to beprovisioned for each of the CRUDoperations for critical enterprise datato maximize reuse.
Service CommunicationStyle
Given the pervasive use of WebServices in SOA implementations,request-reply is often thought to bethe only single communication style.In fact, SOA has several communi-cation styles, including asynchro-nous no-reply mechanisms whichenable event-driven SOA.
The types of possible communi-cation styles include:
• Synchronous communicationrequires direct connectionbetween services. Like a tele-phone call, the other party mustbe available in order for the com-munication to take place.Synchronous communicationsare often blocking — no furtherprocessing can occur until a replyis received.
• Asynchronous communicationis like an email or telephonemessage.The message is sent toa queue, and read at anothertime. There is no live sessionmaintained with the requestor.The actions are non-blocking,
[CONTINUED ON PAGE 10]
BUILD your SOA
Creating Reusable Service Patterns
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 5
MANAGE your SOA
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 6
By David A. Kelly
Sometimes even a buzzword hasmeaning. Take the notion of “gover-nance.” As in corporate gover-nance, IT governance and yes, nowSOA governance.
To some extent, governance isthe latest marketing buzzword.Think of it as the paperless officecraze in the 1980s, updated for the21st century with its implied focuson control and efficient manage-ment of IT (or application orSOA) environments.
Over the past few years,it’s been hard to escape themarketing slant of gover-nance. While it’s a some-what overused term, I don’tthink it’s one that’s goingaway anytime soon. Over the pastfive years we’ve seen a dramaticchange towards much greaterscrutiny and cost/benefit analysis ofIT investment and returns. The gen-eral focus we’ve seen on gover-nance is a result of this generalbusiness pressure for higher profitsand reduced technology invest-ment. As a result, organizations,CIOs and IT managers are leverag-ing portfolio management practicesto justify, expand and explain thevalue and benefits of their ITresources through the use of ITgovernance approaches.
Even though the term is over-used, it still fills a need for organiza-tions that need to find ways to quan-tify and qualify the IT or applicationinvestments they’re making anddefine a strategy for control andmeasurement for their investments.I believe that IT governance, SOAgovernance and application gover-nance will continue to hold value forboth business and IT leaders overthe next few years.
In fact, recent shifts towards SOAhave increased the need for arational IT/applications/SOA gover-
nance strategy, regardless ofwhether you call governance ormanagement or something else.Service-oriented architectures aremuch more complicated than tradi-tional programming models andeffective implementation requiresefficient utilization and re-utilizationof resources, something that’s diffi-cult if not impossible without adefined (or implicit) IT governancestrategy — at least on a projectlevel.
Governance implies responsibili-ty. Good governance means thatyou know what you’re doing andwhy. Weak governance implies thatthe IT (or business) leadership don’thave clear ideas of what they’redoing and why. Implications of weakgovernance include everything fromredundant projects to ineffectiveapplications to IT groups with noclue as to what the business reallyneeds.
On the other hand, strong IT gov-ernance includes aspects of maxi-mizing the value of IT investments,improving communication betweenbusiness and IT, delineating anddefining responsibilities, efficientuse of resources and good projectmanagement.
In general, good IT governancecapabilities and practices meanmore efficient IT systems, more effi-cient use of corporate resources,and greater IT ROI.
Taking it a bit further, it’s helpfulto explore what role governanceand good management play inSOA. Keep in mind that good SOAgovernance includes managementof both the individual services lifecy-
cles as well as the infrastructurethat supports SOA.
SOA governance establishespolices around services. As youwould expect, many organizationsinitially viewed SOA managementand SOA governance as a luxury —a nice thing to have, but somethingthat would have to come after pilot-ing and perhaps even deployingtheir initial services. However, asorganizations grow in their maturityand are coming increasingly rely on
SOA-based infrastructure,lifecycle issues (from SOAtesting to SOA manage-ment to SOA governance)have suddenly become sig-nificantly more important.
Indeed, as organizationsstart deploying production
applications based on SOA, man-agers and developers need to shifttheir focus from simply developingand deploying services to manag-ing, tracking, maintaining and moni-toring services and the SOA infra-structure on an on-going basis.That’s where good SOA manage-ment capabilities and SOA gover-nance policies come into play.
SOA governance should reallybe considered as part of a broaderIT governance strategy. And ascomplex as SOA solutions them-selves can be, and as thorny as theassociated management and gov-ernance issues can also be, SOAgovernance doesn’t need to beoverbearing and heavy. Indeed, oneof the most significant aspects ofSOA-based solutions are their flexi-bility and adaptability. These keybenefits need to be retained.
While we need to manage serv-ices and SOA infrastructure, at thesame time it’s important not to puttoo many restrictions in place or toomany governance processes inplace that will be come overly bur-densome to the development andmanagement of services. Essen-
Once you've defined and implemented SOAgovernance structures, policies and procedures, it's just as important to monitor and manage the
services and processes on an ongoing basis.
The Increasing Need for SOA Governance
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 6
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 7
tially, the goal is to create enoughprocess and structure around theservices lifecycle that can ensureconsistent development, deploy-ment and management processes.SOA management can’t be aboutslowing the process down or restrict-ing the benefits of SOA. Instead,SOA management should be aboutempowering people and enablingthem to create and manage SOAservices and infrastructures in astructured and accountable way.
One the key aspects of SOA man-agement that’s different from tradi-tional IT management — well, per-haps not completely different — is itsfocus on uniting business and IT. Inorder to truly be effective, SOA man-agement needs to ensure and lever-age a tight relationship betweenbusiness needs and objectives andthe IT delivery of the services andthe infrastructure. Also, because ofthe infrastructure nature of SOAsolutions, they need to be managedfrom both a vertical IT project per-spective (how well are we doing onthis project) as well as a horizontalinfrastructure (and future applica-tion) perspective (how well does thisservice fit into our overall strategyand future needs?).
Although it takes more effort tocreate an effective SOA manage-ment strategy, SOA managementmatters because when it’s done rightit can help create more flexible SOAenvironments, reduce the amount oftime it takes to develop and manageSOA environments, mitigate risks,ensure consistency across servicesand business processes andincrease opportunities for reuse. Butthere are other benefits as well.Good SOA management can helpcreate closer and more effectiveteams, establish metrics and ways tomeasure performance and establishbroader and better communicationsbetween the business and IT side ofthe house.
Over the past few years, SOAmanagement and governance hasevolved and matured as more andmore organizations have started toimplement SOA projects and infra-structures.
Let’s take a closer look at someof the basic phases that organiza-tions typically go through as theystart to implement SOA governancecapabilities. The place that mostorganizations start with SOA man-agement is in establishing a need.This usually occurs with the first pilotproject, although the actualresponse to that need may wait untilfuture projects. In either case, thefirst step towards management isusually done in the policies, proce-dures and roles areas — definingappropriate policies and methodsfor enforcing them, establishing gov-ernance frameworks, creating cen-ters of excellence (or at least start-ing to collect best practices), anddeveloping operational procedures.Of course, many organizationsshould start to look at SOA manage-ment (and testing!) tools and appro-priate supporting infrastructure forapplying good governance policies.
The next step is to deploy man-agement solutions incrementally. Inmany cases, the speed of deploy-ment will vary depending on non-SOA factors, such as what types ofmanagement tools and policies anddevelopment lifecycle processes anorganization already has in place.With experience, some companiescan move much faster than others.
Of course, once you’ve definedand implemented SOA governancestructures, policies and procedures,you need to monitor and managethe services and processes on anon-going basis. In this regard, youalso need to make sure you’re tak-ing in other aspects that can affectyour governance policies, includingcultural changes (what happens ifyou acquire or are acquired by
another organization?), changes instandards (how to migrate and providecontinuity for services) and even busi-ness policy changes.
Keep in mind, though, that onceyou start evaluating developmentprocesses and attempting to definegovernance policies and procedures,you’ll probably start identifying whereyour existing development lifecycleprocesses or management processesare weak.You might find, for example,that testing is a particularly weak area(and one that can be particularly trou-blesome as an organization movesinto SOA) or the deployment andoperational metrics are lacking.
As I noted initially, governance is abig, broad concept that can be appliedto just about anything IT or businessrelated these days. But, at the sametime, it’s still something that rationalbusiness and IT managers respond to— who wouldn’t want to have good“governance” over their IT (or applica-tion or SOA) investments. Governanceimplies strong management, goodcontrol and fiscal responsibility — allvirtues that have become incrediblyimportant in this post-Enron SOX-ori-ented regulated environment. Andthey’re all critically important aspectsof a well-run SOA environment. ebizQ
ebizQ analystDavid A. Kelly isan expert in Webservices,applicationdevelopment,and enterpriseinfrastructures.As the formerSenior VP of
Analyst Services at Hurwitz Group,he has extensive experience intranslating the implications of newapplication development,deployment, and managementtechnologies into practicalrecommendations for enterprisecustomers. Reach him [email protected].
About the Author
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 7
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 8
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 8
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 9
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 9
meaning that the requestor con-tinues processing while waiting fora reply. Asynchronous communi-cations are more scalable thansynchronous communications.
• Request reply is a communica-tion where a consumer, or anotherservice, makes a direct request toa provider service, and theprovider replies. The interaction isusually synchronous and block-ing, although it is possible to havenon-blocking asynchronousrequest/reply interactions.
• One-to-one message basedcommunications are generallyasynchronous and non-blocking.An event triggers a request to aservice. The provider serviceprocesses the request when itbecomes available, and then(optionally) replies via a message.This creates loosely coupled com-munications which providegreater agility and scalability.
• Publish and subscribe commu-nications are a broadcast type ofcommunication. Services sub-scribe to information based ontopic or event, and the informationis distributed to those on the sub-scription list. Publish and sub-scribe is an asynchronous non-blocking form of communicationuseful when the originating servicedoes not need to be aware of thedownstream consuming services.
An enterprise SOA will likelyinclude all types of interactions. Thekey is to know when to use whichtype of interaction.
Service Behavior PatternsWe have defined three groups of
service behavior patterns. An individ-ual service can include a combina-tion of behavior patterns.
The first group reflects the job ofthe service:
• Worker is a service that performsa requested function or process. Aworker can be information bear-ing, or change the state of theentity it works on.
• Monitor is a service thatobserves something and reportson its findings based on monitor-ing and notification rules.
• Agent is a service that observessomething and then acts on itsfindings, such as providing infor-mation to a monitor, generatingan event, or invoking a service.
A service can either be stateful orstateless. It must be one or theother.
• Stateful behavior means thatthe state of the service is activelymanaged, for example in a trans-action. Until the transaction hascommitted, the resource(s) mayneed to remain locked.The trans-action then either must success-fully commit or be rolled back.Process-oriented services areexamples of stateful services.
• Stateless behavior means thatthe state of the service is notretained between service invoca-tions, or over time. The vastmajority of services are state-less.
Services that include transac-tions can either be short or longlived. Essentially this refers to theshelf life of the transaction.
• Short-lived transactions aremeasured in nanoseconds ormachine processing time. Anexample would be updating anaccount balance. Short-livedtransactions are usually statefuland synchronous.
• Long-lived transactions cantake minutes, hours, days, evenweeks. Distributed processeswhich cross organizationalboundaries often include long-lived transactions. An examplewould be provisioning a tele-phone service, or a drop ship-ment from a third-party supplier.Long-lived transactions are asyn-chronous and have state thatmust be persisted in the system.
ConclusionThe above framework for charac-
terizing types of services can helpdevelopers understand the differenttypes of services that need to bedesigned. It will help classify servicetemplates for common patterns,such as a stateless service thataggregates information from multiplesources, or publishes information.Over time these templates willbecome building blocks for creatingreusable business services.
Currently companies are gainingsubstantial ROIs from deployingcommon intermediary services thatare reused across projects.Increased business agility will comefrom developing business servicesand processes that can easily bechanged. Increased reuse will comefrom developing the finer-grainedprovider services. As organizationsprogress down the SOA path andbuild out all the types of services,ROI and business agility will increaseexponentially. ebizQ
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 10
SOA: BUILD IT FROM PAGE 5
About the Authors
Beth Gold-Bernstein is thedirector of ebizQTraining Center.She is arecognizedexpert in e-businessintegrationtechnologies
and SOA, Beth is the author of“Enterprise Integration: TheEssential Guide to IntegrationSolutions” and “Integration andSOA: Concepts, Technologies, andBest Practices.”
BrendaMichelson isprincipalconsultant ofElemental Links.She is an ITstrategist, hands-on practitioner,and the voice ofbusiness-driven
architecture. Brenda spent 19years in corporate IT, most recentlyas Chief Enterprise Architect forL.L. Bean. Brenda is a regularblogger on ebizQ.
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 10
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 11
ebizQ Buyer’s Guide
Sonic products from Progress Software help IT organizations achievebroad-scale interoperability of IT systems and the flexibility to adapt thesesystems to rapidly changing business needs. The Sonic products includeSonic MQ, the industry’s only continuously available JMS enterprise messag-ing system, and Sonic ESB, the world’s first and market-share leading ESB.Sonic products simplify the integration and flexible reuse of diverse and oftenproprietary business systems by manipulating them as modular, standards-based services.
Progress Actional delivers Web services management and SOA governanceproducts that provide visibility, security and control of the activities of servic-es and end-to-end business processes in the runtime environment. ActionalWeb services management and SOA governance capabilities include systemand process-level visibility, as well as policy enforcement across an SOAinfrastructure deployed on any combination of platforms. The combination ofthe Sonic and Actional products establishes Progress as a leading provider ofplatform-independent, enterprise-grade SOA infrastructure software.
Progress SoftwareCorporation14 Oak Park DriveBedford, MA 01730, USA(781) 280-4000Toll Free: 800-477-6473www.progress.com/actional www.progress.com/sonic
Products
1. Progress®Actional LookingGlass ™
1. Progress® SonicESB®
LiveCycle™ software helps organizations streamline, inte-grate, and secure business processes within and beyond thefirewall — whether users are online or offline. Adobe’s com-prehensive Process Management Suite includes a highlyscalable workflow engine for integrating human and systemactivities, robust user work portal and ui design tools,process modeling, business rules, and fully integrated busi-ness activity monitoring engine with dashboards.
Adobe Systems Inc. 345 Park AvenueSan Jose, CA 95110-2704USA(408) 536-6000www.adobe.com
Products
1. Adobe LiveCycleProcessManagement
2. Adobe LiveCycleInformationAssurance
■ IBM WebSphere Business Modeler can be used todefine, model, analyze, simulate, and report businessprocesses. It is open standards-based, operating on theEclipse IDE.
■ IBM WebSphere Process Server helps implement &deploy scalable business processes. Process Serverincorporates WMQ Workflow, WebSphere ESB andWebSphere Partner Gateway into one single product sousers can easily deploy and choreograph business tasks.
■ IBM WebSphere Business Monitor uses visualdashboards to provide business process performanceviews.
Products
1. WebSphereBusiness Modeler
2. WebSphereProcess Server
3. WebSphereBusiness Monitor
Ensemble is innovative integration software that provides adramatically faster way to transform organizations into real-time connected enterprises, rapidly linking internal and exter-nal people, processes and applications — while preservingIT investments. Plus, Ensemble enables existing applicationsto be easily enhanced with browser-based user interfaces,rules-based business processes, adaptable workflow thatreduces custom programming requirements, and more —without rewriting.
Products
1. Ensemble
InterSystemsCorporationOne Memorial DriveCambridge, MA 02142(617) 621-0600www.InterSystems.com
IBM Corporation Route 100Somers, New York 10589Check IBM site for phone and fax
numbers in your area.http://www.ibm.com/contact/us/http://www-306.ibm.com/software/
info/bpmsoa/
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 11
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 12
ebizQ Buyer’s Guide
Cape Clear 880 Winter StreetSuite 300Waltham, MA 02451(781) 622-2258www.capeclear.com ProductsCape Clear 6.7
TIBCO Software Inc.3307 Hillview Avenue Palo Alto, CA 94304(650) 846-1000www.tibco.com
ProductsTIBCO BusinessWorks
Java CAPS contains everything an enterprise needs to devel-op and deploy an SOA platform for the re-use of existingapplications, the delivery of new services, and to enable lega-cy and packaged applications to rapidly integrate within anexisting infrastructure. The Suite is SOA-based, fully integrat-ed, and delivers a rich set of integration and composite appli-cation capabilities.
Products
1. Java CompositeApplicationPlatform Suite
2. Java ESB Suite
3. Java B2B SuiteSUN Microsystems4150 Network Circle Santa Clara, CA 95054(800) 555-9786www.sun.com
HostBridge Technology1100 E 7th AveStillwater, OK 74074(405) 533-2900www.hostbridge.com
ProductsHostBridge
Denodo Technologies 530 Lytton Avenue, Suite 302Palo Alto, CA 94301(650) 566-8833 www.denodo.com
ProductsDenodo Platform 3.5
Axway, Inc. US HQ: 8388 E. Hartford Drive, Scottsdale, AZ 85255Europe HQ: 26, rue des Pavillions, FR 92807 Puteaux, CEDEXAsia/Pac HQ: 8 Shenton Way, #31-01 Temasek Tower,
Singapore 068811 (480) 627-1800, or (877) 564-7700 www.Axway.com
ProductsSynchrony Collaborative Business Framework
The information in this Buyer's Guide is provided by the vendors, who take sole responsibility for its accuracy.
JOIN THE BUYER'S GUIDE TODAY!Call ebizQ today to secure your spot on the map
Publicize you solution in ebizQ's premier Buyer's Guide for integrationsolutions and you'll get in front of thousands of interested buyers.
ebizQ's unique, custom-built web and print advertising will enhance your marketing efforts and generate leads. Your company will enjoysustained visibility for a full year, bringing it to its rightful position
on integration technology buyers' short lists.Call Lisa DiBiasi at ebizQ sales at (914) 712-3340
Visit our online buyer's guide for our complete listing of technology vendors at
http://www.ebizq.net/vendors
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 12
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 13
COMPLIANCE &INDUSTRY SOLUTIONS
ebizQ INTEGRATION ROADMAPThe ebizQ Integration Roadmapdefines different types of integration solutions, and the integration services that can be utilized to implement
the business solutions. Below is a comprehensive listing of vendors who provide those technologies and solutions. Using the map, you’ll be able to identify the vendors and solutions that can help you solve your specific integration problems.
COMPOSITEAPPLICATION SERVICES
ACI Worldwide AxentisBancTecBEA SystemsCelcorpCisco SystemsCognizant Technology
SolutionsCordysDataMirroreMag SolutionsExtolFrictionless CommerceFujitsuGrand Central
CommunicationsHubspani2 TechnologiesIBMiGrafxHewlett-PackardInterSystemsIntraxItemfieldiWay SoftwareMagic SoftwareMetastormMicrosoftMovarisNetformxNetik.comOraclePegasystemsPervasive SoftwareQuovadxProgress SoftwareReactivitySAPSeeBurgerSonic Software Sterling Commerce Stone Bond TechnologiesStratus Technologies SUN MicrosystemsSybaseTealeaf TechnologyTeradataTIBCOVerticalnetVitriaWARP SolutionswebMethods
ACI WorldwideAdobe SystemsAlgorithms SoftwareAngoss SoftwareApplixArcplanBEA SystemsBoard M.I.TBusiness ObjectsCACape Clear SoftwareCartesisCelequestCisco SystemsClaraviewCognosCordysCorVuDATALLegroFYI CorpInfor and Extensity HyperionIBMiGrafxInterSystemsInformation BuildersKnightsbridge SolutionsLongview Solutions
MetaMatrixMicrosoftMicroStrategyNavigator Systems NetezzaNoetixOracleOutlookSoftPanorama SoftwareProgress SoftwareSASSiebelSPSSSUN MicrosystemsSunopsisSybaseTeleran TechnologiesTemtecTeradataTIBCO
ActimizeACI WorldwideAction TechnologiesAdobe SystemsAvoka TechnologiesAxwayBEA SystemsBlueTieBMC SoftwareCaptarisCelequestCitrix SystemsCordysCorticon TechnologiesE2OpenEnterworksExtolFiorano SoftwareFujitsuGeneXusGlobal 360Global eXchange Services Grand Central
CommunicationsHandySoftHummingbirdHyperionIBMIDS ScheeriGrafxInformaticaIntalioInterSystemsIntraxiSpheresiWay SoftwareLombardi SoftwareMagic SoftwareMetastormMicroStrategyMQSoftwareNastelNovellOpen TextOraclePegasystemsProgress SoftwareQuovadxSASSavvionSonic Software Sterling Commerce Stone Bond TechnologiesSUN MicrosystemsSybaseSyntheanTacitTIBCOVerilytics TechnologiesVignetteVitriawebMethods
Above All SoftwareACI Worldwide Adobe SystemsAttachmateAvoka TechnologiesAxwayBEA SystemsBMC SoftwareBorland SoftwareCape Clear SoftwareCast Iron SystemsCisco SystemsCordysDataMirrorDenodo TechnologiesFiorano SoftwareFujitsuFusionWareGrand Central
CommunicationsHewlett-PackardHitachiHostBridge TechnologyHubspanIBMInterSystemsIONA TechnologiesiWay SoftwareJboss GroupKenameaMagic SoftwareMetastormMicrosoftMQSoftwareNovellOraclePegasystemsPolarLakePramati TechnologiesProgress SoftwareReactivitySAPSeagull Software SOA SoftwareSoftware AGSonic Software Sterling Commerce Stone Bond TechnologiesSUN MicrosystemsSybaseTIBCOTmax SoftVitriawebMethodsWestbridge Capital
Partners
Above All SoftwareAction TechnologiesActuateArbutus SoftwareASG Software Solutions AttachmateAttunityAxwayBEA SystemsBusiness ObjectsCelcorpCertiveComposite SoftwareContivoCorticon TechnologiesDataMirrorDenodo TechnologiesFileNetFusionWareGlobal 360HandySoftHewlett-PackardHummingbirdIBM
Infor and Extensity InformaticaInformation BuildersInStranetInterSystemsInterwovenIntraxIpedoiWay SoftwareJourneeLogicLibraryMagic SoftwareMediasurfaceMetaMatrixMetastormObtreeOpen TextOraclePercussion SoftwarePervasive SoftwareRaining DataRedDotSagentSnapbridgeSoftware AGSonic Software Sterling Commerce Stone Bond TechnologiesSybaseTIBCOTridionUnicorn SolutionsVitriawebMethods
Adobe SystemsBEA SystemsBlueTieCACordysDataMirrorDataspliceExtolGrand Central
CommunicationsHewlett-PackardIBMIDVelocity InterSystemsIONA TechnologiesMagic SoftwareMetastormmPortalOraclePegasystemsProgress SoftwareRangeGateSonic Software SybaseSylogistTIBCOXora
Above All SoftwareACI Worldwide Adobe SystemsArt Technology Group (ATG)AttachmateAttunityAxwayBEA SystemsBlueTieBroadVisionCACambian Business
ServicesCast Iron SystemsCelcorpCisco SystemsCitrix SystemsCape Clear Software
Cleo CommunicationsClickCommerce.comCompuwareContivoCordysCyclone CommerceDataDirect Technologies DataMirrorDataspliceE2OpenExtolFiorano SoftwareFusionWare CorporationGlobal eXchange Services Grand Central
CommunicationsGT SoftwareHostBridge TechnologyHewlett-PackardHubspanHummingbirdi2 TechnologiesIBMIDVelocity InovisInterSystemsIONA TechnologiesiSoftItemfieldiWay SoftwareJacadaKenameaMagic SoftwareMetastormMicrofocusMicrosoftMITEMmPortalMQSoftwareNetik.comNetManageNovellOraclePegasystemsPervasive SoftwarePolarLakeQuovadxRangeGateReactivityRed OakSAPScribe SoftwareSeagull SoftwareSeeBurgerSEECSiebelSoftware AGSonic Software SpiritSoftSterling Commerce Stone Bond TechnologiesSUN MicrosystemsSybaseSylogistTIBCOVignetteVitriawebMethodsWestbridge Capital
PartnersXoraYantra
Adobe SystemsAltirisAmberPointArambh NetworkAttachmateAxwayBEA Systems Blue Titan SoftwareBMC SoftwareBusiness Objects
CAContivoDataMirrorElectronic Data Systems
Corporation (EDS)Fiorano SoftwareGeneral DynamicsGrand Central
CommunicationsHewlett-PackardHubspanHyperionIBMInformaticaInformation BuildersInterSystemsIONA TechnologiesiWay SoftwareMagic SoftwareMercuryMetastormMicrosoftMQSoftwareNastelNovellOracleOraclePegasystemsProgress SoftwareReactivitySOA Software Sonic Software Sterling Commerce Stone Bond TechnologiesSUN MicrosystemsSybaseTIBCOTumbleweedVitriaWestbridge Capital
Partners
ACI Worldwide Adobe SystemsBEA SystemsCordysElectronic Data Systems
Corporation (EDS)Hewlett-PackardHubspanIBMiGrafxInterSystemsIONA TechnologiesIpedoiWay SoftwareMagic SoftwareMetastormMicrosoftMQSoftwareNastelOraclePegasystemsPervasive SoftwareProgress SoftwareReactivitySoftware AGSonic Software Sterling Commerce Stone Bond TechnologiesSybaseTIBCOUnisysVitria
INFORMATIONINTEGRATION
PROCESSINTEGRATION
APPLICATIONINTEGRATION
INTERFACE INTEGRATION
MANAGEMENT& SECURITY
BUSINESSOPTIMIZATION
ARCHITECTURE &DEVELOPMENT
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 13
and technically feasible services. Abottom-up analysis of every candi-date service, however, requires asignificant amount of time to accom-plish.
We save time by creat-ing the high-level serviceblueprint using the top-down approach and thenproviding more detail onlyfor strategic services atthe business process anduse case level. Strategicservices are definedusing IT portfolio manage-ment techniques to identi-fy strategic business pro-cesses and IT assets.This provides a fully-pop-ulated service catalogwith more details for the
services that will be created early inthe SOA transformation.
Portfolio management tech-niques can be used to identifystrategic services. Here, we seek tovery quickly identify the top priorityservices by tying them back to busi-ness processes and then assessingthe current effectiveness and criti-cality of the business processes thatthey will potentially support. Weconsider the company’s strategicobjectives and how our core servic-es and business processes supportthem. This step is essentially aprocess to prioritize, score and cat-egorize business processes and thesupporting services. Scores can beplotted in four quadrants to identify
services with the most potential ben-efits as shown in figure 3.
We then examine only the high-priority candidate projects and serv-ices in more detail to avoid spendingtime on services and projects are noton the SOA Roadmap short-term.This results in more detail for upcom-ing projects and less detail for proj-ects that are further out on theroadmap. This process creates theStrategic Services Blueprint. Theblueprint and roadmap details thefuture-state service catalog and pro-vides a roadmap on how to get to thefuture state in terms of people,processes, projects and technology.
The SOA Strategic Roadmap Once you have the blueprint, you
need to plan how the services will bebuilt out over time. SOA is a transfor-mation that will often take years toachieve. It is important to think of tac-tical projects, new packaged applica-tions and the existing portfolio interms of the SOA blueprint. Forexample, if you have a tactical proj-ect that touches an IT asset thatpotentially supports a strategic serv-ice, then expose the service as partof the tactical project. Without aroadmap and blueprint, such oppor-tunities would be missed.
Build the SOA Roadmap in termsof projects, services, people,processes and technology asdetailed in figure 4. For example,early SOA projects might be basedon exposing legacy applications as a
foundational set of services. Laterprojects might be more focusedon leveraging these services inautomated, composite businessprocesses. In this scenario, SOAintegration technology and thepeople skills and processesaround this technology would beearlier in the roadmap than busi-ness process management soft-ware, skills, etc.
The Strategic ServicesBlueprint provides a strategicview of services to be built overtime yielding the following bene-fits:
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 14
perspectives and provide a meansfor IT to collaborate with the businessto determine what services are of thehighest value.
There are several ways to consid-er the business in functional terms.An analysis of the human factors ofservice-orientation gives us theimpact of SOA on the company’sconstituents. For example, customer-facing services frequently yield thegreatest returns. We therefore oftenanalyze services within the businessboundaries of customers, products,suppliers and human resources,which can yield benefits such as:
• Support customer service initia-tives
• Improve integration with businesspartners
• Streamline the supply chain
• Enable employee self service
• Facilitate global product lifecy-cle management
Once we have a vision for thecompany’s core services, we canplan how to build and deploy theservices (service realization). Abottom-up analysis examineslegacy systems and componentsin an effort to realize the servicesdefined in the business domainsand discover services that werenot uncovered in the top-downapproach. Looking at servicesfrom the top down and the bottomup validates the definition of useful
Figure 3
Figure 2
SOA: PLAN IT FROM PAGE 4
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 14
• Identify services that support therequired business functionalityand processes.
• Align the IT projects with a servic-es strategy and desired businessprocess functionality.
• Establish and adhere toservices architecturalrequirements for per-formance, scalability,and security.
The StrategicServices Blueprint willanswer the following criti-cal questions to the suc-cess of SOA:
• What are the core serv-ices needed to optimizethe business?
• What services shouldbe built first?
• What is the architectureand infrastructure forservices over time?
• Where do we need to make strate-gic investments?
• How can tactical projects impactthe buildout of the services cata-log?
THE INSIDER’S GUIDE TO BUSINESS INTEGRATION WINTER 2007 www.ebizQ.net 15
Figure 4The Strategic Services Blueprint
provides the means to plan andcommunicate a SOA transformationover time. The planning approachand team organizational structurehelps to manage change, ensurereuse and align SOA with businessobjectives. ebizQ
Eric Roch is ChiefTechnologistand NationalPracticeDirector forSOA atPerficient Inc.Eric developsstrategic plans
for SOA and is responsible forPerficient’s SOA methodologyand software. He can becontacted [email protected].
About the Author
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 15
ebizqInsiderWinter06.qxd 11/8/06 5:15 PM Page 16
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 4 1
any given time in the mushy process, I’m supposed to fork over the information they need (for that process step) and then they are allegedly supposed to take me to the next step in the process. We’re supposed to play this back-and-forth game until I reach the end state of my quest. It’s really like playing a Parker Brothers game … if you play Monopoly with your eyes closed and let the family dog act as the banker. Sadly, in this game of governmental dice, I’m the only one who seems to care about moving the process forward. For example, when I last spoke to the agency, they said they would “get back to me” about the next step in my quest. The process ball was in their court and they dropped it. The agency hasn’t gotten back to me. They’ve effectively forgotten I exist. My bureaucratic friends lack process memory. They require me, the alleged customer, to keep track of the process state. I now have to call and remind them of where they are in the process flow. That, my friends, is a process failure. The customer must not be the sole source of process memory; the customer must not be the one to drive the process forward. As it is, I’m the only one who remembers I exist in this process. I’m the only one who remembers there is a next step pending. I’m the only one who remembers I already have been through five steps in the flow. This agency has process memory loss and who suffers? I suffer; the agency is blissfully unaware of pain. The moral is simple: If you want to succeed in the process world, process memory is an absolute requirement. Don’t make your customers maintain the state of the process. Take pride in your work and keep your eyes on the ball, and not on the clock. Master this, and you’re well on the way to process excellence. Screw it up, and you are just another bureaucrat in a brown polyester suit. bij
About the AuthorDavid McCoy is managing vice president and associate chief fellow for Gartner, the world’s largest IT research and advisory firm. At Gartner, he manages the Business Process Management team and actively researches BPM concepts and technologies. He has an extensive background in IT, including past roles as software developer, entrepreneur, college instructor, and consultant. He’s a long-time columnist and contributing editor to BIJ, and an active speaker and academic guest lecturer on IT topics. His “Renaissance Man” column uses humor and analogy to examine the deeper implications of our evolving relationship with IT. Email: [email protected] Website: www.gartner.com
this column ends the series on the job attributes of process excellence—the ongoing test to see if you “have
what it takes” for the wonderful world of process. I feel I must end this now or my next column may well be “A Liver for Process.” Sometimes I scare myself. Before someone gets hurt, let’s end this metaphorical journey with the most critical requirement of all: process memory. Let me illustrate the concept with a case study. For the past months, I have been “dealing” with a governmental agency. Like most of my dealings with governmental agencies, I’m playing my standard, well-honed role of feudal supplicant, bowing before a dusty throne and seeking alleged assistance and protection. As demeaning as that sounds, such is my role in the script of life, whenever I act on the same stage as the brown-suited bureaucrats. As I struggle to make sense of arcane rules and bad, bad customer service, I keep running into the same major process roadblock. Bluntly, the problem is one of memory, or lack thereof. My worthy opponent—in this case a bewildering agency, chock full of clock-watchers—doesn’t care to remember me, nor does it care to remember our interactions. They have a full-blown case of process memory loss. Process memory: Time exists because life has a flow about it. You are born, you grow up, you get married, you have children, you work for 30 years and then you retire with full benefits, a pension, and a new Cadillac every other year … Oops. Sorry. I was reading Best American Short Stories of 1946 again. Forget that retirement fiction, but don’t forget time. Time reminds us there are certain things that have to happen in a certain order. Memory exists to remind us of the past-time events. If we put these together—time and memory—and take them to the land of process, we get the following axiom: In order for a process to work effectively over time, you have to remember what you have already done, where you are now, and what comes next. This is process memory. The geeks may think of this as being “state-aware”—no matter—having process memory means you know the facts about the process at hand. Now, let’s return to the example of process memory loss; my ongoing struggle with governmental powers. When I “deal” with this government agency, I’m allegedly participating in a process—one they control. I can’t see the process; it isn’t explicit. I can only experience the process. At
r E n a i s s a n C Em a na m e m o r y f o r p r o c e s s ? i ’ m s t i l l H e r e !
B Y D a v i D m c C o Y
P roponents of Service-Oriented Architecture (SOA) promise a lot, including lower develop-ment costs, increased agility,
greater ability to reuse assets, and better alignment of development with busi-ness requirements. Haven’t we heard this all before? It seems every integra-tion approach put forth in the past 30 years has promised these things, but few have delivered. In some ways, SOA is dramatically different from prior integration approaches; in other ways, it’s similar. By examining how development approaches have evolved to SOA, it’s easier to understand the benefits and set proper expectations.
In the Beginning In the beginning, integrating appli-cations meant connecting two end-points, which was relatively simple. If something changed with one endpoint, the impact of that change on the inte-gration could be quickly identified and the integration edited, if necessary. However, complexity increases as appli-cations and systems are added, and today typical integrations have thou-sands of connection points and intricate interdependencies (see Figure 1).
If any single connection is changed or broken, the impact of that change ripples through the infrastructure with unpredictable consequences. This has important ramifications. When a busi-ness unit requires a change to one of its existing applications, it’s typically impossible to provide the business unit with a realistic cost or timeframe for completing the change. To the applica-
tion owner, this often represents unac-ceptable cost and delay in achieving objectives.
To Centralize (or Not) As enterprise systems mushroomed in complexity, the one-to-one integra-tion model could no longer serve enter-prise needs. Enterprise Resource Planning (ERP) systems, designed from the ground up to run the most impor-tant business processes, were developed with an eye toward reducing the com-plexity of integration. Unfortunately, they were commonly implemented as large, monolithic application suites; and because ERP systems cost so much, companies sought to maximize ROI by leveraging them across as many busi-ness units as possible, with all associated decision-making and implementation controlled by a corporate-level ERP committee. With this approach, indi-vidual business units must limit their application needs to what will work with the specific ERP system. This greatly limits flexibility. The alternative, EAI, sought to cen-tralize and control how multiple appli-cations were integrated. It concentrated the responsibility and knowledge for integration into the hands of relatively few people—integration broker users—which, ironically, reduced the agility of the individual business units that need-ed integration support. As systems changed, developers had to change all related interfaces in the EAI tool—a costly, time-consuming process. This approach tended to lock enterprises into applications and severely limited their ability to adapt to change.
4 � • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure1:AnActualProcure-to-PayDiagram
Can SOA Finally Deliver on the Promise of Enterprise Integration?By Jake Freivald
Lessons Learned From ERP and EAI With ERP and EAI, business process owners—those individuals closest to the problems they’re charged with solv-ing—must conform to the application, ERP system or broker, or work to define common processes with competing groups that have their own problems to solve. Political battles often ensue and solutions require compromises. Business process owners gain little control over the processes they’re responsible for. The attempt to frequently centralize didn’t work. Forty to 60 percent of busi-ness units maintained additional appli-cations or systems, separate from the main ERP system, to retain some con-trol over selected processes. For the enterprise, the result is expensive. Even after multi-million dollar investments in the ERP system and other systems, everyone receives part of what they need, but few business units receive everything they need. Moreover, orga-nizations often ended up with both ERP and EAI technologies—a costly propo-sition. Application companies are starting to change their tune. Vendors such as SAP and Oracle are adopting a less cen-tralized approach—offering new prod-ucts and splitting elements out to offer a more “open” alternative. For example, SAP Exchange Infrastructure (XI) func-tions similarly to a broker, enabling dif-ferent SAP installations to more easily communicate with each other. SAP NetWeaver and Oracle Fusion seek to improve information accessibility by allowing use of other applications as services. By breaking apart the system and using other applications as services, the main NetWeaver or Fusion system can control the way services and appli-cations are used and retain everything on the ERP platform. ERPs still provide value to the enter-prise, but they are best used as a rich repository of application services. When these services are exposed and imple-mented correctly, they can be used in many ways without compromising reuse.
The Pendulum Swings Having experienced the shortfalls of centralization, enterprises returned to decentralization. Common Object Request Broker Architecture (CORBA), a particularly rigorous approach, was intended to make things interoperable, but high interoperability required a well-defined set of standards to ensure all objects communicated exactly the same way and no adjustments were required. CORBA used an Object Request Broker (ORB) to communicate using interfaces defined in the Interface Definition Language (IDL). Based on that, anyone should be able to talk to any other ORB and access any service. But the IDL memory layout adhered to a strict standard that was difficult to work with and often required as many specialists as there were different ser-vices or applications. The more com-plexity, the more time and specialists were required. These project time and budget constraints are the main reason CORBA remains unpopular.
Flexibility With Web Services Integration approaches have come full circle with the advent of SOA and Web services. The difference between Web services and CORBA is the degree of flexibility and interoperability each provides. To fully appreciate that, you need an accurate understanding of what SOA and Web services really are. Start with these three facts:
• SOA is a set of best practices that includes ways to effectively use Web services.
• Web services are a set of technology standards.
• Web services fit in SOA, but by them-selves aren’t enough to build a solid integration approach.
The Web services vision is based on having a network standard, using XML and HTTP, that functions similarly to a broker. A developer should be able to
call any kind of service to applications through standard Web services—and have the transaction work perfectly. Application platforms such as Java and Microsoft .NET, Web portals, and other enterprise applications are service con-sumers. Each source of specific services has a Web services interface and com-municates with the Web services net-work.
Why Web Services Aren’t Enough Web services are extremely helpful in simplifying integration, and they bal-ance flexibility and interoperability. While these characteristics are benefi-cial, they alone don’t prevent complex “spaghetti” integration. Web services are neutral; there are basic ways to imple-ment Web services and better ways to implement them. Suppose a developer builds an appli-cation to provide a bank with credit risk data about customers. Part of the appli-cation relies on census data (e.g., aver-age income and age group). Due to mergers, this bank has two systems that contain customer credit data (PeopleSoft and SAP) and each has different services (see Figure 2). A problem the developer must solve is: “Get average income for people living near this address.” Even though our developer is using Web services to obtain census data, he still must know many things about the applications. Immediately, the task becomes difficult. To extract the correct data from each system, the developer must know the existing application structure, applica-tion security requirements, appropriate metadata, and transaction management aspects—attributes unique to each application. The new applications are tightly coupled to existing applications. If the PeopleSoft application is upgraded, the credit risk application must be upgrad-ed. Because Web services are built to promote reuse, more developers will be calling those services directly and they’ll be tightly coupled to many applications.
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 4 3
BuSInESS • SOAsupportsbusinessneedswithoutforcingprocessestomatch
softwaretemplates.• SOAkeepsitspromisesofaligningITwithbusinessoperationsfor
localownership,lowercosts,andbetterresults.
TEChnOlOgy • Inaperfectworld,Webservicesinteroperabilitywouldmakeiteasy
tointegrateanythingandeverything,andallapplicationswouldconformtoWebservicesstandards.
• Centralizedapplicationintegrationdoesn’tnecessarilymeanallapplicationsarecentralized—40to60percentofbusinessunitsmaintainadditionalapplicationsorsystems,separatefromthemainERPsystem,toretainsomecontroloverselectedprocesses.
Web services implemented in this rather indiscriminate way yield the same prob-lem as previous integration approaches: unmanageable complexity. So Web services alone don’t consti-tute solid integration architecture. Instead, what’s needed is the ability to use Web services to enable business process owners to define and pay for the services they need at a process level, simultaneously allowing developers to decouple service invocations from ser-vice interfaces. This can be achieved through the Enterprise Service Bus (ESB).
How ESBs Help In SOAs, the ESB provides a com-mon point of communication between business process owners’ service requests and IT’s service implementa-tion. A Web service exposed via an ESB doesn’t contain any low-level informa-tion in it—only business-level informa-tion. These high-level Web services let the process owner understand the ser-vices he requests and they let IT imple-ment the services in the way they must be implemented, regardless of underly-ing technology. An ESB places responsi-bility for the business information solution with the person closest to the problem—the process owner (see Figure 3). A process owner may be a director of sales who needs to provide his sales channel with near-real-time inventory data so they can reserve product for customers or balance the demands for multiple customers in the event of a shortage. He knows what data he needs for accomplishing his task and where the pieces of information reside. What he doesn’t know, and shouldn’t
have to know, is how the application must be accessed, what application interdependencies exist, or which tech-nical capabilities are required to imple-ment the new services. In an SOA environment, the director requests a service, using only business-level infor-mation, from his assigned IT resources. Then the IT team composes the service in the ESB from existing systems and applications using Web services (see Figure 4). By enabling the business to request a business-level interface, such as “get current inventory,” IT aligns precisely with what the business needs. To create the business-level interface, developers use an ESB to orchestrate low-level sys-tem calls into a service; they then expose that service using Web services. Now, everyone can call the ESB to change an
existing service or add a new one. Service composition isolates the busi-ness from change and lets process own-ers manage and request services that meet their needs. The ESB properly routes and transforms requests to underlying applications, letting devel-opers make one change in the ESB instead of many changes to myriad related services and applications (see Figure 5).
Managing SOA With ESBs In a perfect world, Web services interoperability would make it easy to integrate anything and everything, and all applications would conform to Web services standards. In reality, many applications aren’t Web services-based. So a successful integration will include robust support for Web services stan-dards but won’t be limited to that. The ESB must be able to tap into any stan-dards. Here’s the beauty of ESB in SOA: When the ESB is standards-compliant, it can work with applications conforming to a wide range of standards, and any developer or process owner can interact with it in a standards-based way. Like CORBA and stand-alone Web services, SOAs using an ESB provide a decentral-ized approach to delivering services for greater flexibility. Unlike CORBA and ERP, the SOA and ESB approach pro-vides loosely coupled, business-level interfaces like those achieved with inte-gration brokers. But unlike ERP systems, the SOA lets you tailor services specifi-cally and update them easily without affecting other applications.
4 4 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure2:WebServicesAloneDon’tMeanYouHaveaGoodArchitecture
Differences Between Web Services and CORBAWeb Services COrBA• Pushes responsibility for • Focuses on ORB and often creating service to the endpoints requires custom code• Web Services Description Language • IDL memory layout standard (WSDL) is easy to manage; cross- difficult to work with platform XML standard • Emphasized interoperability;• Added rigor to flexible standards flexibility an afterthought
SOA Implementation Pitfalls SOA delivers the advantages of the approaches that led to it, but remember that SOA is a set of best practices, not a technology. SOA provides a powerful, easy-to-use approach for building out sustainable applications and services. However, when developers don’t adhere closely to SOA best practices, they’re doomed to repeat past failures. The following are common mistakes organizations make when building SOAs:
• Calling Web services at will: Only Web services that have been architect-ed correctly and expose a high-level interface should be used. Calling low-level Web services results in spaghetti integration. Only business-level Web services should be reused.
• Tryingtoprovidecentralizedcontrolover an ESB: ESBs are decentralized integration brokers. The goal is to let each process owner control his own services. When control is centralized, process owners won’t receive every-thing they need in a service—just like in an EAI environment.
• Tryingtoforcetheentireenterpriseto use the same standard “public”interfaces: Domain owners should be prepared to keep their interfaces pri-vate instead of mapping everyone else to them. Forcing standard public inter-faces is unrealistic. Enabling domain owners to keep their interfaces private is the best way to maximize flexibility.
• LockinginonanERPvendor’sworldview: This should be done only in one-ERP shops, if ever.
A Promising Future SOA provides decentralization with appropriate centralization where required. It supports business needs without forcing processes to match soft-ware templates. It removes much of the pain historically associated with main-taining applications on a long-term basis. For these reasons, SOA keeps its promises of aligning IT with business operations for local ownership, lower costs, and better results. bij
About the Author Jake Freivald is vice president of Product Marketing for iWay Software. As a leader in SOA solutions, iWay Software provides highly interoperable solutions that enable organizations to create, compose, and manage services, whether invoked as Web services or through other interfaces. Email: [email protected]: www.iwaysoftware.com
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 4 5
Figure3:ESBandItsPositionBetweenBusinessProcessOwnerandIT
Figure4:ServiceComposition
Figure5:WebServicesandExistingSystems
On October 12, 2006, the Organization for the Advancement
of Structure Information Standards (OASIS) announced approval of the Reference Model for Service Oriented Architecture (SOA-RM) v1.0 specifica-tion. The reference model is intended to define the essence of SOA, as well as provide a vocabulary and common understanding of SOA. It provides a normative reference that remains rele-vant for SOA as an abstract, powerful model, regardless of the inevitable tech-nology changes that have influenced or will influence SOA deployment. Conflicting definitions of SOA have emerged as a result of significant atten-tion it has received and addressing that problem was part of the motivation for creating an open standards reference model for SOA (see “The Next Wave: SOA Reference Models are Appearing ... Now What?” by David S. Linthicum, July/August Business Integration Journal). A reference model is an abstract framework for understanding signifi-cant relationships among the entities of some environment. More specifically, a reference model consists of a minimal set of unifying concepts, axioms, and relationships with a particular problem domain, and is independent of specific standards, technologies, implementa-tions, or other concrete details. Consistent with this level of abstrac-tion, the OASIS SOA-RM was created to provide its audience:
• A common conceptual framework that can be used consistently across
and between different SOA imple-mentations
• Common semantics that can be used unambiguously in modeling specific SOA solutions
• Unifying concepts to explain and underpin a generic design template supporting a specific SOA
• Definitions that should apply to all SOA.
At 31 pages, SOA-RM is relatively brief and easy to read in its entirety; it includes normative and non-norma-tive references, a glossary, and acknowledgements. Section 1 introduces the specifica-tion and provides usage guidance. Section 2:
• Defines the SOA paradigm• Introduces the principal concepts
defined in Section 3• Includes a worked SOA example based
on an electric utility use case• Differentiates SOA from other software
paradigms such as object orientation.• Articulates some of the benefits of
SOA.
Section 3 introduces the formal Reference Model for SOA centered on the core concept of service and sup-ported by the concepts related to the dynamic aspects of services and meta-level aspects of services (about services). Section 4 addresses compliance with the reference model. Section 5 lists normative and non-normative references.
Appendix A provides a glossary with concise definitions of terms. A full description in the text is the normative description, not the concise definitions provided in the glossary. Appendix B lists members of the OASIS SOA-RM Technical Committee who helped develop the specification.
Unifying Theme of SOA Paradigm SOA-RM defines SOA as “a para-digm for organizing and utilizing dis-tributed capabilities that may be under the control of different ownership domains.” The discussion of SOA con-tinues with a description of entities (people and organizations) as the cre-ators of capabilities to solve or support a solution for the problems they face. These entities offer capabilities and act as service providers. Those who make use of services are called service con-sumers. This section also touches on correlation and granularity of needs and capabilities. The perceived value of SOA noted is that SOA provides a powerful framework for matching needs and capabilities and for combining capabili-ties to address the needs. This perceived value is the unifying theme on which the SOA-RM standard is based. Key concepts for describing the dynamic aspects of service in the SOA paradigm are:
• Visibility, the capacity for those with needs and those with capabilities to see each other.
• Interaction, the activity of using a capability to realize one or more real-world effects, where a real-world effect is the actual result of using the service. An interaction is fundamentally “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects).
• Real-worldeffects form an important part of the decision on whether a par-ticular capability matches similarly described needs.
Each of these key concepts and their relationship to each other is fully char-acterized in Section 3 of the specifica-tion, a section that documents the normative elements of the SOA-RM. Section 2 attempts to distinguish between an SOA service and the more general concept of service. The latter is typically defined as the performance of work (a function) by one for another. While both needs and capabilities exist independent of SOA, in SOA, services are the mechanism by which needs and
4 6 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Introducing the OASIS Reference Model for Service Oriented Architecture BY JEFF A. ESTEFAN
capabilities are brought together.
Key Principles Reviewed The specification defines seven prin-cipals, starting with the introduction of the core concept of a service itself (see Figure 1). This is followed by the intro-duction of concepts that relate to the dynamic aspects of services (visibility, interaction, real-world effect) and final-ly, the introduction of concepts that refer to the meta-level aspects of services (service description, contract and poli-cy, and execution context). The relationships between these principal concepts are developed as each concept is defined and intro-duced; this alleviates a significant amount of cross-referencing between them. A full description of the princi-pal concepts of the standard and the relationships between them is described in Section 3. Only a brief description of each is provided here. A glossary is provided in Appendix A to help clarify some concepts; the full description is in the text that’s the normative part of the specification.
Service The specification defines service as “a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with con-straints and policies as specified by the service description.” This is consistent with the definition of SOA discussed earlier. There are other important norma-tive elements of the SOA-RM provided as part of the formal description of ser-vice that relate to service participants (consumers and producers), service functionality, and service opaqueness.
Dynamics of Services There are three fundamental con-cepts important to understanding the dynamics of services (see Figure 2):
• The v isibi l ity between ser vice
providers and consumers• The interaction between them• The real-world effect of interacting
with a service.
Visibility is the relationship between service consumers and providers that’s satisfied when they’re able to interact with each other. The reference model states that “the initiator in a service inter-action must be aware of the other parties, the participants must be predisposed to interaction, and the participants must be able to interact.” These three pre-condi-
tions to visibility are called awareness, willingness, and reachability, respectively. Relationships among and further descrip-tion of these concepts supporting visibil-ity appear in Section 3.2.1. Interaction is the activity involved in using a capability offered, usually across an ownership boundary to achieve a particular desired real-world effect where the real-world effect is the actual result of using a service. Interacting with a service involves performing actions against the service. Often, this is accomplished by sending and receiving
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 4 7
BuSInESS • TheOASISReferenceModelforSOA(SOA-RM)v1.0Specification,an
OASISstandard,providesacommonvocabularytotalkaboutSOA.• ThestandardspecificationprovidesanormativereferenceforSOA
asanabstractandpowerfulmodeltobeleveragedinternallyandwiththeextendedenterprise.
• UnifyingconceptsareprovidedbytheformalspecificationtoexplainandunderpinagenericdesigntemplatesupportingaspecificSOA.
TEChnOlOgy • SOA-RMisneutralwithrespecttoSOA-relatedtechnology
standards.• Thestandardspecificationisalsoneutralwithrespectto
middlewaresuchasSOAPservers,messagebrokers,andtheEnterpriseServiceBus(ESB).
• TheSOA-RMspecificationistwolevelsofabstractionawayfromspecificSOAimplementations.SpecifictechnologymappingsareexpectedfollowingdevelopmentoftheSOAreferencearchitecture.
Requirements
Abstract
Concrete
ReferenceArchitectures
Patterns
Architecture Work
Service Oriented Architecture Implementations
ReferenceModel
guided by
FIGURE 1
FIGURE 4
FIGURE 2
FIGURE 3
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
derivedaccounts
for
accounts for constrained by use
considers
ConcreteArchitectures
RelatedModels
Motivation
Goals
Protocols
Pro�les
Speci�cations
Standards
Related workInput
Figure2:PrincipalConceptsintheOASISReferenceModelforSOAv1.0SpecificationAssociatedWiththeDynamicAspectsofServiceNote:Thetrianglesdepictingdynamicsofservicesandmeta-levelaspectsofservicesareforillustrativepurposesonly(i.e.,theyaren’tpartofthenormativespecification).
Requirements
Abstract
Concrete
ReferenceArchitectures
Patterns
Architecture Work
Service Oriented Architecture Implementations
ReferenceModel
guided by
FIGURE 1
FIGURE 4
FIGURE 2
FIGURE 3
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
derivedaccounts
for
accounts for constrained by use
considers
ConcreteArchitectures
RelatedModels
Motivation
Goals
Protocols
Pro�les
Speci�cations
Standards
Related workInput
Figure1:PrincipalConceptsintheOASISReferenceModelforSOAv1.0Specification
messages, although the reference model allows other modes that don’t involve explicit message transmission. Key con-cepts important to understanding what’s involved in interacting with services revolve around the service description, which references an information model and a behavior model. The service description is one of the principal con-cepts of SOA-RM that’s associated with the meta-level aspects of services. The information model is used to capture both the structure (syntax) and seman-tics (meaning) of the information that may be exchanged with the service. The behavior model is used to capture knowledge of the actions invoked against the service and the process or temporal aspects of interacting with the service. Each of these important con-cepts and their relationship in support of interaction are documented in Section 3.2.2. Real-world effect is the actual result of using a service, rather than merely the capability offered by a service pro-vider. This may be the return of infor-mation or the change in state of entities involved in the interaction. This notion of shared state often leads to confusion but it simply represents shared informa-tion about the affected entities as part of a service interaction between service participants (producers and consum-ers). In other words, the shared state is the set of facts and commitments that manifest themselves to service partici-pants as a result of interacting with a service.
About Services The remaining three principal con-cepts that compose SOA-RM are a set of concepts about services themselves; in
other words, the meta-level aspects of services (see Figure 3):
• The servicedescription• The executioncontext of the service• The contractsandpolicies that relate
to services and service participants.
Service description represents the information needed to use or consider using a service. Its purpose is to facili-tate interaction and visibility between participants in service interactions. This is particularly important when the par-ticipants are in different ownership domains. The service description usu-ally references an information model and a behavior model. In addition, a service description may contain addi-tional elements such as service func-tionality and service reachability. The purpose of documenting the service functionality is to unambiguously express the function(s) of the service and the real-world effects that result from its invocation. The purpose of documenting service reachability is to provide sufficient data to enable a ser-vice consumer and service provider to interact with each other. Another important element of the service description is the service inter-face, which provides the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real-world effects as specified through the service functionality portion of the service description. A service description may include support for associating policies with a service and providing necessary information for prospective consumers to evaluate if a service will act in a man-
ner consistent with the consumer’s con-straints. The subject of policies and contracts is another meta-level aspect of services. Each of these important con-cepts and their relationship supporting service descriptions is documented in Section 3.3.1. Contracts and policies are, together, an important principal concept of SOA-RM. A policy represents some con-straint or condition on the use, deployment or description of an owned entity as defined by any participant. A contract is an agreement between two or more parties. Understanding this dis-tinction in definition and scope is important because it’s often a source of confusion. The reference model focuses primarily on the concept of policies and contracts as they apply to services rather than the form or expressiveness of any language used to express policies and contracts. Related to the concept of service policy are the notions of:
• Policy assertions, which are measur-able and often about the way the ser-vice is realized. A policy always represents a participant’s perspective.
• Policy owner, sometimes referred to as policy subject.
• Policy enforcement amounts to ensur-ing that the policy assertion is consis-tent with the real world.
Policies potentially apply to many aspects of SOA: security, privacy, man-ageability, Qualities of Service (QoS), etc. Beyond such infrastructure-orient-ed policies, participants also may express business-oriented policies such as hours of business, return policies, etc. Like service policies, service con-tracts can cover a wide range of aspects of services such as QoS, interface and choreography agreements, and com-mercial agreements. As stated earlier, a contract represents an agreement between two or more participants. While a contract may be expressed in a form that permits automated interpre-tation (as a policy assertion might), where a contract is used to describe over-arching agreements between ser-vice providers and consumers, then the priority is likely to make such contracts readable. Service contracts and policies and their relationships are documented in Section 3.3.2. Execution context of a service inter-action is the set of infrastructure ele-ments, process entities, policy assertions
4 8 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Requirements
Abstract
Concrete
ReferenceArchitectures
Patterns
Architecture Work
Service Oriented Architecture Implementations
ReferenceModel
guided by
FIGURE 1
FIGURE 4
FIGURE 2
FIGURE 3
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
derivedaccounts
for
accounts for constrained by use
considers
ConcreteArchitectures
RelatedModels
Motivation
Goals
Protocols
Pro�les
Speci�cations
Standards
Related workInput
Figure3:PrincipalConceptsintheOASISReferenceModelforSOAv1.0SpecificationAssociatedWiththeMeta-LevelAspectsofService(AboutServices)Note:Thetrianglesdepictingdynamicsofservicesandmeta-levelaspectsofservicesareforillustrativepurposesonly(i.e.,theyaren’tpartofthenormativespecification).
and agreements identified as part of a service interaction, and that form a “path” between those with needs and those with capabilities. This notion of execution context may seem unfamiliar but it’s important. Envision the service participants as two separate places on a map and, for a service to be invoked, a path must be established between the two places. This path is the execution context. All interactions are grounded in a particular execution context, which permits service providers and consum-ers to interact and provides a decision point for any policies and contracts that may apply. Execution context is detailed in Section 3.3.3.
Relation to Other Work Section 1 of SOA-RM describes how the reference model relates to other dis-tributed systems architectural inputs in terms of levels of abstraction, starting with the highest level—the reference model itself—down to the most con-crete level in terms of SOA implementa-tions. Figure 4 illustrates these levels of abstraction. An SOA-RM subcommittee is work-ing to develop one or more reference architectures in support of the reference model. A reference architecture is at least one level less abstract than a refer-ence model and differs from a reference model in that it describes an architec-tural pattern that indicates how an abstract set of mechanisms and rela-
tionships realizes a predetermined set of requirements. The relationship between different levels of architecture and an example from a housing domain use case are included in Section 1.1. The first public draft of the OASIS Reference Architecture for SOA (SOA-RA) is expected in the mid-2007 timeframe. Another deliverable that’s in prog-ress is a Reference Model for SOA Primer. This primer will help provide additional guidance and best practices on the use of the SOA-RM specifica-tion. Moreover, an effort is under way to harmonize some of the key concepts and definitions for SOA being pursued by other open standards bodies such as The Object Management Group (OMG) and The Open Group. The OASIS SOA-RM Technical Committee has appointed a liaison to serve as a contact point for other standards bodies that wish to col-laborate on this activity. Contact infor-mation for selected members of the OASIS SOA-RM Technical Committee appears at the end of this article.
Conclusion Given the immense interest in SOA, development of a vendor-neutral, open standards-based reference model for SOA was sorely needed. The SOA-RM specification is intended to provide a common framework that can be used consistently across and between differ-ent implementations, and to provide
common semantics that can be used unambiguously in modeling specific solutions. In addition, the specification is intended to provide:
• Unifying concepts to explain and underpin a generic design template supporting a specific SOA
• A common vocabulary to talk about SOA that applies to all SOA.
As your organization begins to con-sider adopting this new standard, it’s important to thoroughly read the speci-fication. Unlike most industry stan-dards, this one isn’t only technology-neutral, it’s relatively short. Be sure to read all supporting text sur-rounding each of the seven principal concepts for SOA. It may take several readings to fully digest the fundamental concepts, but with each read, the con-cepts will seem a little less abstract. Finally, while it may be tempting to simply adopt the SOA-RM specifica-tion as an industry-standard lexicon for SOA, it will be far more effective to leverage the standard during your organization’s business and IT trans-formation initiatives. The standard can help the stakeholders involved better understand the underlying concepts and relationships surrounding SOA. That’s the intent of the new standard from OASIS. bij
Web Resources:• OASIS: www.oasis-open.org/home/index.php• SOA-RM: www.oasis-open.org/specs/index.
php#soa-rmv1.0 • Wikipedia: http://en.wikipedia.org/wiki/OASIS_
SOA_Reference_Model
SOA-RM Technical Committee:• Chair: Duane Nickull, Adobe Systems Inc., [email protected]• Secretary and Standards Liaison: Francis McCabe,
[email protected]• Secretary: C. Matthew MacKenzie, Adobe Systems
Inc., [email protected].
About the Author Jeff A. Estefan is a principal engineer with the NASA’s Jet Propulsion Laboratory in Pasadena, CA. He’s the division chief technologist for the Systems and Software Division at JPL and a voting member of the OASIS Service Oriented Architecture Reference Model (SOA-RM)
Technical Committee and OASIS SOA-RM Reference Architecture (SOA-RA) Subcommittee.Email: [email protected]: www.jpl.nasa.gov
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 4 9
Requirements
Abstract
Concrete
ReferenceArchitectures
Patterns
Architecture Work
Service Oriented Architecture Implementations
ReferenceModel
guided by
FIGURE 1
FIGURE 4
FIGURE 2
FIGURE 3
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
Visibility
ExecutionContext
Real-WorldE�ect
ServiceDescription
Interaction
Service
Contract& Policy
derivedaccounts
for
accounts for constrained by use
considers
ConcreteArchitectures
RelatedModels
Motivation
Goals
Protocols
Pro�les
Speci�cations
Standards
Related workInput
Figure4:HowtheReferenceModelRelatestoOtherWork
Since the Sarbanes-Oxley (SOX) Act went into effect at the end of 2004, publicly traded companies have struggled to meet their dead-lines due to the massive effort this legislation requires. Specifically, Sections 404 and 302 are a persis-
tent challenge. These regulations man-date documenting internal controls, measuring and testing the effectiveness of key controls, reporting and correcting deficiencies, and certifying the effective-ness of their control environment, requir-ing a high degree of coordination between employees, consultants, and auditors. Leading up to, and immediately fol-lowing enactment of the law, the market was flooded with vendors and special-ists promising compliance expertise. Unfortunately, many of these self-pro-claimed experts had to go through the same learning process as their custom-ers. So early SOX compliance approach-es were improvised and relied on custom spreadsheets and highly manual con-trol, test, and audit procedures. The first versions of compliance software were either custom-built to support the indi-vidual methodologies of the consul-tants, or billed as one-size-fits-all solutions that proved to be far too rigid in the long run. Early compliance solutions helped early adopters manage the cost and complexity of the new regulations. Yet one of the pitfalls common to enterprise applications remained—the instinct to treat the software deployment as a one-time purchase and project, a quick fix that needed no further attention. Compliance has to become a habit; the key financial controls and testing proce-dures used to ensure accurate reporting must be ingrained in the organization’s daily operations. As companies work to meet ongoing SOX requirements, they realize compli-ance is more than just an annual docu-mentation exercise. It’s a continuous dynamic process that requires extensible technology to automate, monitor, and optimize their testing, audit, documen-tation, and remediation procedures.
A Process, Not a Project While deploying compliance soft-ware is a project in itself, and testing and audit cycles also are worthy of being individual projects, SOX compli-ance requires these projects to be per-formed regularly. A long-term, cost-effective compliance approach, therefore, should focus on managing and optimizing the complete compli-
5 0 • B u s i n e s s I n t e g r a t i o n J o u r n a l • N o v e m b e r / D e c e m b e r 2 0 0 6
Making the Case for
Process-Based, Sarbanes-Oxley
ComplianceBy Jim Coleman
ance cycle, with an eye toward continu-ous process improvement. In the early stages of compliance efforts, minimum accomplishments should include:
• Fully automating the documentation process and testing procedures
• Tracking all control exceptions or test failures and their resolutions
• Enabling attestation and certification of the results.
Software deployed for compliance should implement Treadway Commission’s Committee of Sponsoring Organizations (COSO) framework for risk management and corporate finan-cial reporting. A COSO-framework architecture ensures full documentation of all processes, risks, key controls, and tests needed to guarantee the accuracy of signoff. The software must also sup-port complete automation of the docu-mentation process, ensuring all relevant documentation is collected and main-tained. The software should identify key areas where documentation is lacking, and the progress of testing efforts. Next, major processes (including testing, identification of issues, and res-olution plans) should be automated. Tracking testing progress and the reso-lution of test failures increases the accu-racy of the data gathered and instills greater confidence in the overall com-pliance effort. Management begins to gain insight into the manner by which compliance may be deeper ingrained into daily operations. Unfortunately, this is where many manual compliance efforts and applica-tions stop. Analytics is left to external Business Intelligence (BI) or data ware-housing applications, process definitions are stored in document format, docu-mentation is stored in external systems, and coordination of work is relegated to email. Limitations to internal scalability become apparent when the compliance effort includes teams in the hundreds. To optimize performance and gain
full insight into control effectiveness, more powerful tools need to be deployed to manage tasks, analyze performance, and integrate with other corporate IT systems.
BPM Suites for Process Improvement Business Process Management (BPM) suites reduce the risk of purely manual operations by automating tests while increasing visibility into opera-tions through active control monitoring and real-time analytical reporting. Custom business rules and notifications can help detect and proactively alert management to issues. By combining the document-centric and task-based workflow approaches, along with ana-lytics and integration capabilities, BPM suites provide a perfect fit for building a compliance framework. More important, by focusing on the process rather than the outputs, BPM suites gain a considerable advantage over checklist-style applications, since a process-centric approach can be easily adjusted to take advantage of lessons learned or to account for regulatory change. Decision thresholds for test fail-ures, changes in ownership and respon-sibility, survey coverage and focus are examples of common changes to com-pliance efforts. Unlike the simple task routing and approval functionality available from older workflow tools, BPM Suites (BPMS) provide flexible, powerful tools to model, execute, and optimize real-life processes. In BPMS-based solutions, the templates provided for SOX represent a starting point for best-practices deploy-ment; the fundamental logic of the pro-cesses may be altered to support individual needs. Advanced BPM fea-tures may be exposed to a key team of compliance process specialists to opti-mize process instances through in-flight modifications, and through the creation of new process versions that increase throughput and certainty. Well-defined processes ensure the right people get the right tasks at the
right time, with complete transparency of performance throughout the organi-zation. Full activity and input audit trails ensure reviews are possible down to the most granular level, and excep-tion-handling features allow for in-flight debugging of problems by triggering and assigning issue remediation pro-cesses to the appropriate teams. Notifications can alert management to severe problems, with links to monitor the problem and resolution, without having to wait until the close of an approval cycle—when it’s too late. Besides the information contained in the COSO data, BPMS-based compli-ance applications also provide the ability to attach supporting documentation to tasks and processes. These attachments may include electronic copies of samples used during testing, historical snapshot reports, links to external imaging sys-tems, or even collaborative spaces in the corporate intranet. Integrated search capabilities allow for later retrieval with-out forcing users to rely on memory alone. By centralizing all required knowl-edge into the same single-source applica-tion that’s used for completing and managing work associated with the com-pliance effort, organizations drastically improve the efficiency of their teams.
Full Process Orchestration Reporting capabilities are vital to any compliance project. Without the ability to verify the control state, or progress against full documentation goals, both management and the com-pliance team are effectively flying blind. However, with the full integrated ana-lytics capabilities of a BPMS-driven approach, reports and metrics need not be limited to dashboards and exported reports. The compliance team should focus on the effort to include analytics everywhere—on all task screens, in every task assignment and escalation, and also in alerts and notifications. The increased compliance transparency that inevitably results helps organizations actively manage compliance issues,
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 5 1
BuSInESS • SOXcomplianceisacontinuousprocessthatrequiresextensible
technologytoautomate,monitor,andoptimizereporting,review,anddocumentationefforts.
• CombiningworkflowandBIapplicationsisastepintherightdirection,butnotaspowerfulasanintegratedBPMsuite.
• SOXsolutionsbuiltusingaBPMsuiteprovideanidealapplicationplatformtodeployacomplianceframework.
TEChnOlOgy • Sections404and302ofSOXareapersistent,expensive,and
challengingrequirementforpubliccompanies;theissueofcomplianceisn’tgoingaway.
• Compliancepracticesshouldbecentralizedandstandardizedtocreateanenvironmentthatyieldsreliableinformationaboutfinancialcontrolperformance.
• Properlyimplemented,BPMsuitescanbeusedtocompetitiveadvantagebyenablingcontinuousprocessimprovement.
Phase One: Approach SOX as a process, not a project________________________________________________
COMPONENT WHY BPMS?________________________________________________
Centralize the 404 Documentation effort
A BPMS coordinates work between compliance teams and auditors, and ensures the work is always completed. Additionally, a BPMS can provide powerful native document management capabilities or integrate into existing file and image stores. Cross-linking these systems allows for effective centralization of all supporting documentation during the testing and audit periods.
________________________________________________
Automate the testing effort By automating the testing procedures, along with the rules for initiating the tests (timers, conditions in data, etc.), the goals driving the test become more closely monitored and are reinforced.
________________________________________________
Track all control exceptions and their resolutions
A BPMS ensures all work assigned is completed with a full audit trail. Responsible parties are always notified of assigned work, and in the event of slow response times, escalation rules may be created to notify management or reassign work to other groups with a lower workload.
________________________________________________
Provide all relevant testing and control information for signoff by executives. Gather 302 surveys to support it.
Surveys are a natural fit for a BPMS. Integrated group and identity management allows for flexible rules to populate the recipient list with the appropriate people.
________________________________________________
5 � • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
A Three-Phase Approach to Implementing Process-Based Compliance
Phase Two: Process improvement________________________________________________
COMPONENT WHY BPMS?________________________________________________
Fully automate manual controls: Analyze the controls to find decision points where people are forced to take the same actions and automate them. Simplify the tasking procedure.
A BPMS provides elegant human-to-human task assignment and collaborative work environments, as well as powerful integration capabilities to gather information from external back-office applications. Fully automating today’s manual controls helps to minimize the risk of human error and improve overall performance by reducing execution times by relying on direct communication with external systems.
________________________________________________
Improve control effectiveness: Monitor performance across all controls to identify deficiencies.
By monitoring the global state of compliance efforts, a BPMS helps reveal weak links in the process framework. Driving analytics back into the process during execution also enables direct improvement by tightening controls.
________________________________________________
Decrease testing times and costs: Monitor task execution performance and identify which tests are behind schedule.
Flexible analytics for ad hoc reporting and bottleneck analysis can help identify performance issues with testing. Besides increasing the certainty of control effectiveness, consuming analytics during execution also may drive escalation rules to improve human performance times.
________________________________________________
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 5 3
Phase Three: Process Orchestration________________________________________________
COMPONENT WHY BPMS?________________________________________________
Analytics everywhere: Integrate performance and business reports into the compliance processes, drive task escalations based on past performance and test exceptions based on real-time data.
By driving the performance metrics and business data back into the process, a BPMS can help automatically provide continuous performance improvements, reducing costs and turning compliance into a competitive advantage.
________________________________________________
Active control monitoring: Processes implementations should take into account external data and systems to accurately report status and handle control exceptions.
A BPMS supports direct integration to back-office financial and ERP systems and custom-developed applications, letting the processes respond to remote events and data entry as they occur in real-time.
________________________________________________
Auto-create issues: The system should detect failures or inconsistencies in controls. Use the software to auto-create investigation and remediation procedures to identify and fix exceptions.
Sophisticated rules and events management capabilities allow the BPMS to kick off testing, issue tracking, and remediation processes as they occur, based on internal documentation performance or external data.
________________________________________________
Automatically notify management of exceptions and status: When the system creates remediation processes, management needs to be alerted. Likewise, periodic automated status reports from the system help ensure executive visibility into ongoing compliance activities.
BPMS applications allow for configuring alerts as a key feature of their processes. Part of the issue identification and remediation process should include real-time notification and periodic status reports.
________________________________________________
—JC
allowing real-time resolution of issues before they devel-op into material problems. This level of sophisticated, real-time risk management is a primary goal of SOX with business benefits that extend well beyond check-box compliance. Deep integration capabilities also let BPM suites link to corporate Enterprise Resource Planning (ERP) and financial systems, providing active control monitoring independent of manual triggers. The analytics that drive process execution can now take into account the current state of external systems at all times. As content is added to external libraries, processes may be triggered to moni-tor compliance or randomly select the item for testing. Automatic triggering of issues based on external systems and the notifications to management also may be orches-trated through the BPMS. Besides monitoring and notification, integration with external systems also reduces the likelihood of duplicate data. The systems of record need no replacement, but the entire workspace is now managed through the single interface to the BPMS. No more trips between browser windows, copying and pasting; the data is retrieved as needed into task forms and calculation points and attached back to the task or process instance for future reference. By deploying a BPMS solution that combines BPM, content management, real-time analytics, and enterprise integration capabilities in a single centralized suite, orga-nizations can increase visibility and clarity of financial auditing processes. Executives can obtain real-time, actionable business insight about key financial processes and activities, and gain competitive advantage by imple-menting a flexible compliance framework to manage the growing complexity of compliance, minimize the high cost of manual operations, and work toward continuous process improvement. Active management of corporate risk significantly reduces corporate financial risk, while efficient, continuously improving compliance process management reduces compliance costs. Reduced risk and cost control are valuable. In summary, a compliance application should offer these capabilities:
• Import data into COSO-based, industry-specific con-trol frameworks
• Design entity-level surveys for code of conduct and segregation of duties
• Assign control tests and evaluate results • Raise, track, and remediate issues as they occur• Generate personalized, dashboard-style reports using
real-time analytical capabilities• Consolidate audit information into a single, Web-based
environment • Automate, monitor, and streamline specific financial
processes • Integrate security and personalization• Save time and money and realize rapid ROI by auto-
mating best practices. bij
About the AuthorJim Coleman, a senior BPM consultant at Appian Corp., has managed multiple enterprise process and compliance solution deployments since Sarbanes-Oxley took effect in 2004. He has specialized expertise helping organizations manage their Sections 302 and 404 compliance initiatives. Email: [email protected]: www.appian.com
5 4 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
For the past 12 to 18 months, there has been growing interest and discussion surrounding BPMN, XPDL and BPEL. What has begun to take form is the recognition of the BPMN-XPDL-BPEL Value
Chain, a concept first credited to ana-lyst Sandy Kemsley by XPDL expert Keith Swenson (whose work has been liberally borrowed and adapted for this article—thank you, Keith!). In many ways, both literally and metaphorically, this value chain begins with Business Process Modeling Notation, or BPMN for short. Users generally will start by drawing a BPMN diagram, saving the partial diagrams as XPDL during develop-ment, and ultimately translating to BPEL parts of the process focused on data exchange (vs. human interac-tion). BPMN was proposed as the graphical modeling component of the original set of specifications intro-duced by the former Business Process Management Initiative (BPMI), now part of the Object Management Group (OMG). BPMN is a graphical notation that depicts the end-to-end flow of steps and activities within a business process. It provides for modeling the sequence of activities within a process as well as the data or messages that flow between dif-ferent process participants within a related set of activities. In other words, BPMN isn’t designed simply to model applications, but also the processes in which applications would be used. For this reason, the output of BPMN needs to be expressed in something other than programmatic language. This was ini-tially expected to be BPML, a since abandoned meta-language developed by BPMI. What BPMN would have provided through BPML is the direct translation of a graphical model intelligible by peo-ple (i.e., business analysts, process own-ers) into a machine-readable format—to enable the interchange of process defi-nitions between different tools and from different vendors. In the absence of BPML, where do you go with a BPMN model? The answer(s) are found in the next linkages in the value chain—spe-cifically translating BPMN into BPEL and/or XML Process Definition Language (XPDL). One of the common misconcep-tions regarding these standards is that BPEL and XPDL are direct competi-tors or are otherwise mutually exclu-sive. This simply isn’t the case. In fact,
Understanding the BPMN-XPDL-BPEL Value ChainByNathaniel Palmer
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 5 5
BPEL and XPDL are entirely different yet complementary standards, designed for different purposes. BPEL is an “execution language” designed to pro-vide a definition of Web services orc h e s t r at i on — t h e u n d e r l y i n g sequence of interactions, and the flow of data from point to point. The goal of XPDL is to store and exchange the process diagram—to allow a tool to model the diagram, another to read the diagram, and so on. BPMN can be used to model an executable process by constraining dia-gram objects and their properties to that which can be mapped directly to BPEL elements. This enables, albeit with limitations, the use of a BPMN diagram to provide a business-oriented graphical process model that also can generate executable code through BPEL. This presents a real advantage, since BPEL doesn’t have an associated graphical notation nor does it require concepts to support the visual diagram of a process model. Similar to BPEL, the original ver-sion of XPDL developed by the Workflow Management Coalition lacked specific graphical representa-tion. With the release of XPDL 2.0 and subsequent versions, however, it was expanded to include the specific mech-anisms that allow round-trip develop-ment from BPMN to XPDL and back to BPMN. Rather than an executable program-ming language, XPDL is a process design format, which literally repre-sents the “drawing” of the process defi-nition. It has “XY coordinates” and node size, as well as a concept of lines, and points along the line that give it a particular path. The XPDL file can pro-vide this design interchange because it offers a one-to-one representation of the original BPMN process diagram. It can be written and re-read to recover the original diagram. BPEL, on the other hand, is a non-trivial mapping that’s widely recognized as being one-directional (i.e., not round-trip). As previously stated, it’s possible to take a BPMN diagram and produce BPEL, but
it’s difficult or impossible to recover the original BPMN diagram from the BPEL. But that’s OK—BPEL wasn’t designed for process design inter-change, whereas XPDL was designed precisely for this purpose. Who cares about the ability to inter-change process models anyway? Process interchange offers a key leverage point for firms investing in process models and for those that want these invest-ments to be actionable without being locked into a single vendor. In all our research, as well as that done by others, we’ve found it’s far more common for firms to use tools such as Visio to devel-op process models. Through various third-party extensions, Visio supports BPMN, which by extension means it also supports XPDL—in fact, XPDL has been used specifically for the inter-change of models between XPDL and simulation engines. XPDL and BPMN provide a platform for managing a library of business processes as reusable and accessible business assets. The importance of process design interchange continues to increase as the BPM market matures. The lack of interoperability and design exchange necessitates a vertically integrated model where a single vendor must supply all the tools involved in BPM. This may have been acceptable in the early stages of the market when early adopters were placing bets on individual vendors, but for the market to grow and mature into the next stage, there needs to be an eco-system, not an oligarchy. This ecosystem is visible and grow-ing today, and despite relatively aggres-sive M&A within the BPM sector, the leverage of standards (notably BPMN, XPDL, and BPEL) has provided a plat-form for a host of individual specialized and niche players, as well as the oppor-tunity for larger BPMS vendors to offer a standards-based, round-trip frame-work. These standards also have “glo-balized” the BPM playing field, with a number of firms within emerging mar-kets now not only offering compliant software, but directly contributing to the working groups defining and devel-
oping the specifications. Where domi-nant U.S. and Western European firms haven’t always demonstrated a willing-ness to “play nice” on standards devel-opment, emerging market firms are showing great innovation when it comes to both the development and applica-tion of standards. An important attribute for enabling innovation within this ecosystem is the extensibility mechanism of XPDL. Specialized tools may present unique requirements using extended attributes, and while other tools won’t understand these extensions, they will carry the extensions along the round-trip. For example, a tool specialized to clean up the layout might manipulate the graphi-cal aspects of the model, and return a cleaned up model, including all the extensions, to the original source with-out losing any information. Enhydra JaWE is an open source XPDL editing tool that has been publicly demonstrated to read an XPDL file from Fujitsu’s Interstage BPM, edit, and return without the loss of vendor-specific extensions. Several BPM engines are able to run XPDL natively, which allows run-time modification and process migration to be readily supported. Where these processes focus on broader-scope collaboration among people, they can remain within XPDL/BPMN. Where pieces are decom-posed into system-to-system interactions, these can be translated to BPEL for trans-mission to an EAI-oriented BPM engine. These are three very different and very compatible roles. But that’s the nature of the value chain—BPEL and XPDL are entirely different things for entirely dif-ferent purposes. bij
About the AuthorNathaniel Palmer is president ofTransformation+Innovation as well as the executive director of the Workflow Management Coalition (WfMC), the only standards organization that concentrates purely on process. The WfMC created XPDL and Wf-XML and had influence on BPMN
and other process-related standards. Email: [email protected]
BuSInESS • Processinterchangeoffersakeyleveragepointforfirmsinvesting
inprocessmodelsandforthosethatwanttheseinvestmentstobeactionablewithoutbeinglockedintoasinglevendor.
• Emergingmarketfirmsareshowinggreatinnovationwhenitcomestoboththedevelopmentandapplicationofstandards.
TEChnOlOgy • Theimportanceofprocessdesigninterchangecontinuesto
increaseastheBPMmarketmatures.• SeveralBPMenginesareabletorunXPDLnatively,whichallows
run-timemodificationandprocessmigrationtobereadilysupported.
Many large organizations are reaping the benefits of IT, but paying a
steep price. Years of silo-oriented development, lack of domain architecture, and mergers and acquisition have resulted in technology inconsistencies and a multitude of systems. Lack of resource sharing compounds the diversity issue, increasing the Total Cost of Ownership (TCO) of these systems and making it difficult to adopt a Service-Oriented Architecture (SOA). These problems call into question the benefits of investing in:
• An Enterprise Resource Planning (ERP) “silver bullet” system that meets business needs and provides competi-tive advantage
• Your own next-generation SOA sys-tem that applies service-oriented prin-ciples and leverages best-of-breed Commercial Off The Shelf (COTS) products as well as some in-house development.
A silver-bullet ERP commodity is a myth generated by marketing literature. Most ERP systems excel only in a few functional domains and IT is saddled with the problem of integrating the ERP system with other COTS or in-house products. Large organizations rolling out an ERP system or a next-generation SOA system will face the problem of large-scale integration.
The Large-Scale Challenge Large-scale integration is usually rooted in a Wal-Mart-type technical architecture philosophy. Simple, pro-found ideas implemented on massive scale serve as the basic building blocks for business processes. It’s usually quite difficult or impossible to change tracks midstream in a large-scale integration project, so it’s imperative to make even seemingly simple decisions after careful thought and experimentation. You can’t usually afford the luxury of custom designing every small interface and tak-
ing frequent one-off approaches that deviate from the norm. Diversity of approach has a significant support cost, raises TCO, and should have a compel-ling business value proposition. Yet there’s also the danger of over-simplifi-cation and reducing integration to data transformation and movement via tight-ly coupled point-to-point interfaces. The challenge of large-scale integra-tion is building integration solutions that: • Have a consistent, homogenous archi-
tecture• Are robust and reliable• Scale to meet high-performance
needs• Enable reuse• Are agile and service-oriented • Are supportable.
We’ll examine several elements of technical architecture that can help achieve this goal.
Evangelize Logical Architecture Logical reference architecture is a consistent set of architectural best prac-tices for use by all the teams in an orga-nization. A large organization usually has many different tools that overlap in functionality and different teams that are used to working with different tools. It’s important to draw some guardrails around tool appropriateness for con-nectivity and to test the proposed usage before advocating it. The Integration Center of Excellence or Enterprise Architecture is usually the right team to govern tool usage. A tools and technol-ogy map may run into several pages; a simple block-diagram picture can go a long way in communicating guidelines.
Standardize on an ESB An ESB is a container that unites and connects applications, provides routing and mapping functionality, orchestrates services, and ensures reliable message delivery semantics. It hides the differences
5 6 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure2:Real-WorldView
Figure1:IdealizedView
ErP or Nextgen SOA?By rajiv Totlani & vikas Balakrishna
in platform, software architecture and network protocols. The ESB is the chame-leon that adapts to the different needs of the applications. An ESB also supports incremental integration, making it easy to add components and services in the future. An ESB is extremely important; your organization should make a strong commitment to using it. Figure 1 shows an idealized SOAP-only world where all components adhere to standards, speak the same protocol and can adapt to the needs of a common enterprise language. The real world actually has applications that don’t always follow standards, speak different protocols, and are relatively rigid and inflexible. As shown in Figure 2, an ESB provides the right connectivity and adaptability hooks with greater reliability.
Architect for High Availability High Availability (HA) ensures robustness and reliability of the hard-ware and software infrastructure. It’s among the most important elements of technical architecture and often the most overlooked. HA architecture is an insurance policy for calamities such as file system corruption or failures of the database, machine, service or ESB. There are three different types of HA configurations to choose from, depend-ing on Service-Level Agreement (SLA) requirements: active-active configura-tion, active-passive with hot standby, and active-passive with cold standby. Figure 3 depicts a typical active-passive configuration.
Build Reusable Technical Services SOA is about coarse-grained busi-ness services composed of reusable, atomic services. However, a bigger case for reuse usually lies in technical ser-vices that power the business services and atomic services. Technical services are the “low-hanging-fruit,” usually obvious, and significantly more valu-able. A detailed analysis of the system landscape (using a middle-out system analysis approach rather than a top-down business service discovery approach or a bottom-up atomic build
approach) will usually reveal opportu-nities for technical services and large-scale reuse. Some common technical services in ESB architectures include:
• Logging service• Error handling service• Message replay service• Notification service• Scheduling service• Aggregation/disaggregation service• Encryption/decryption service• Digital signature service.
Some of these services are offered by COTS products and some can be built in-house.
Automate Build, Deployment, and Testing Software bugs are a fact of life. In a large-scale integration effort, consider-able time and money can be saved by automating testing, builds and deploy-ments. Automation in the build-deploy cycle usually includes pulling code directly from the source control system,
creating the deployment archives, deploying to ESB, and versioning the deployment in source control. Utilities that allow repetitively building all or some components with a single click based on some configuration data can be extremely helpful in shortening deployment times. Automated test scripts ensure repeatability of the test cases and measuring of test results. Some COTS tools provide some auto-mated testing capabilities that can be extended to meet project-specific needs. Utilities such as Ant or Maven are fea-ture-rich in providing build-deploy tools but sometimes need to be comple-mented to meet project-specific needs.
Embrace Design Patterns Design patterns ensure consistency of approach at the logical level, and code at the physical level. Reuse is an obvious benefit of patterns. Patterns also ensure stability by using a proven approach. Figure 4 depicts a real-time to batch aggregation pattern using an aggregation service intermediary.
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 5 7
BuSInESS • Inalarge-scaleintegrationeffort,considerabletimeandmoneycan
besavedbyautomatingtestingandbuildsanddeployments.• Diversityofapproachhasasignificantsupportcost,raisesTCO,and
shouldhaveacompellingbusinessvalueproposition.
TEChnOlOgy • Large-scaleintegrationrequiresaconsistenthomogenous
architecturewithahighdegreeofreuseandflexibilitythatanESBcanprovide,butaSOAP-onlyarchitecturecannot.
• Embracedesignpatternstoensurehomogeneityofarchitecture.• Reusetechnicalservicesthatpowerthecoarse-grainedbusiness
servicesandatomicdataservices.
Figure3:Active-PassiveHAConfiguration
Use Canonical Data Models Independently developed applica-tions tend to use different data formats as each format was designed with just
that application in mind. This makes the process of integrating applications extremely difficult as every application needs a data translator to talk to other
applications. Using a canonical data model seems complicated if only a small number of applications participate in the integration solution. However, the solution quickly pays off as the number of applications increases. There are three approaches to adapting an appli-cation to use a canonical format as shown in Figure 5.
Build for Support Support considerations are often omitted in project planning, but some thought to support issues during design and coding can yield better code with-out compromising a project’s timeline or budget. It’s important to seek answers to these questions:
• What’s the end-to-end error handling strategy across systems?
• How can errors in one system be cor-related to data or events in another?
• How is replay handled in case of errors in the source system or middleware?
• How will duplicates be handled in middleware and in the target system?
• How does the system gracefully recov-er and restart after a failure?
• What tools will be used to provide business events visibility and support Business Activity Monitoring (BAM)?
Conclusion The preceding list of success factors for a large-scale integration effort isn’t exhaustive. If you address these ele-ments of technical architecture upfront and adopt appropriate processes and governance, you’ll start the ball rolling in the right direction toward ensuring successful implementation. bij
About the AuthorsRajiv Totlani is an integration architecture expert with PepsiCo. He has helped many large organizations rise to the challenge of integrating their custom and legacy systems with ERP applications. His areas of interest include SOA, open source and Web 2.0 technologies, and especially the areas where these three intersect.Voice: 972-963-6744Email: [email protected] Website: www.pepsico.com
___________________________________
Vikas Balakrishna is a lead developer of U.S.-based consulting company Hydus Inc. At Hydus, he leads a team who work on enterprise integration solutions for a variety of clients, including PepsiCo, Siemens, and Texas Mutual Insurance. He has developed several Web-based integration solutions and has strong expertise in various Java 2 Enterprise Edition (J2EE) technologies. Voice: 609-558-5716 Email: [email protected]: www.hydus.com
5 8 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Figure4:Real-TimeERPtoLegacyBatchPattern
Figure5:CanonicalDataModels
As industry pundits debate the proper
terminology—some calling it 2.0, others next-generation or advanced—there’s no denying that the latest evolution of Service-Oriented Architecture (SOA) is about the impact of real-time events on SOA and the implications this progression has for the real-time enterprise. Understanding the advancement of SOA requires that we establish a baseline for how the term has come to be understood. SOA is an approach for building distributed com-puting systems based on encapsulating business functions as services that can be easily accessed in >
Advancing SOA With Real-Time EventsBy Chris Garner
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 5 9
a loosely coupled fashion, enabling robust, flexible interaction between components. These services can be accessed via a network while the under-lying platform implementation remains transparent to the consumer (whether a person or program), and the location of the source program or data—whether on the same machine or another—is irrelevant to that consumer. While many elements of SOA were in place years ago, what really pushed those elements into widespread adop-tion as an architectural approach was the firming up of industry standards from the comparative anarchy that pre-vailed in the early days of object-orient-ed programming. With viable standards in place, enterprise IT administrators have quickly seized on the benefits afforded by SOA of rapid application development and agility in addressing changing needs. The latest evolution of SOA entails the merging of SOA with other archi-tectural types—especially Event-Driven Architecture (EDA)—to create symbi-otic systems that can exceed the sum of their parts. EDA pertains to creating an architecture that fully leverages the abil-ity to capture real-time state changes (events) as they occur, then dynamically respond or react in appropriate ways as defined by, say, business rules. Unlike SOA, where communications are solic-ited, EDA operates without the event-generating process having any awareness of the “consuming” processes—which may be innumerable and can receive and respond to the events in parallel. Where SOA processes are loosely cou-pled, EDA processes are so autonomous as to often be termed “un-coupled.” What advantages does EDA bring to SOA? When you combine the real-time intelligent aspects of event integration with interoperability and zero latency, this evolved form of SOA can enable businesses to realize what Gartner calls the ”Real-Time Enterprise,” defined as
“an enterprise that competes by using up-to-date information to progressively remove delays to the management and execution of its critical business pro-cesses.” Consider a financial deposit at a bank. Traditionally, a batch system reg-isters all such events and processes them together overnight. That’s not real-time and has a high degree of latency. A complete facility for EDA, by contrast, provides the ability to capture each event as it happens and apply rules to it to perform certain actions, transform the composite data into some interoper-able format, and provide a vehicle for publishing it. Capture-enrichment-transformation-publishing is the equa-tion that defines the new modern tools for supporting an EDA. It’s important to distinguish between events that have an impact on an orga-nization’s business and those that don’t. Event detection has commonly been employed in systems management soft-ware to use network events in normal-izing system operations and maintaining system health. An example might be server load balancing, where real-time capture and response of systemic events prevents processing overload from occurring on any one server. The tech-nical events we speak of in connection with EDA are more business-specific. Where the merging of advanced SOA and EDA have great promise is in using these business-meaningful events to realize aspects of the real-time enter-prise. So, what types of organizations stand most ready to take advantage of SOA complemented by event-driven integra-tion? Applications regarded as SOA 2.0-ready include those in financial services and insurance enterprises. These orga-nizations are already making heavy use of Web services and have been early adopters of SOA. A major reason is the vast amount of business-meaningful events (such as rate changes, investment
grade changes, stock price changes, etc.) that their IT infrastructures must han-dle and react to daily, sometimes on a minute-to-minute basis. These indus-tries are driving the need for real-time event capture and publish in an SOA. Another major reason behind rapid adoption of SOA in the finance and insurance sectors is that these enter-prises rely heavily on the mainframe and legacy applications that typically run on them. Legacy systems were ini-tially designed without modern distrib-uted computing in mind. Until recently, most mainframe integration methods also forced tight coupling. Years of adapting to innovation and growth have increased the complexity of mainframe integration methods; this has led to latency in service perfor-mance and brittle implementations, often based on gateways. The main-frame world has been deliberate, if not slow, to support new applications. Legacy systems often involve sophisti-cated programming, requiring a techni-cal expediency that’s costly and increasingly scarce. Even so, mainframes can’t be ignored. In fact, the majority of Fortune 500 companies rely on mainframes, and more commercial transactions are pro-cessed on mainframes than on any other platform. If an enterprise is considering where best to incorporate events into an advanced SOA, it will likely find the preponderance of these occurring in the highly transactional mainframe envi-ronment. A properly implemented event-driven SOA system can, without touching application code, capture events in real-time from leading main-frame database systems and push them asynchronously via multiple messaging and communication protocols. An advanced SOA should be enter-prisewide. An SOA only achieves true ROI and universal integration through-out a large-scale enterprise by incorpo-rating legacy applications. Enterprise
6 0 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
BuSInESS • EnterpriseITadministratorshavequicklyseizedonthebenefits
affordedbySOAofrapidapplicationdevelopmentandagilityinaddressingchangingneeds.
• Ifanenterpriseisconsideringwherebesttoincorporatebusiness-meaningfuleventsintoanadvancedSOA,itwillfindmostofthemoccurringonthemainframe.
• TheevolvedformofSOAcanenablebusinessestorealizewhatGartnercallsthe”Real-TimeEnterprise.”
TEChnOlOgy • EDAoperateswithouttheevent-generatingprocessbeingawareof
consumingprocesses,whichmaybeinnumerableandcanreceiveandrespondtoeventsinparallel.
• AcompletefacilityforEDAprovidestheabilitytocaptureeacheventasithappensandapplyrulestoitforperformingcertainactions.
• Anevent-drivenSOAsystemcan,withouttouchingapplicationcode,captureeventsinreal-timefromvariousdatabasesandpushthemasynchronouslyviacommunicationprotocols.
developers would be best served lever-aging a single, unified mainframe inte-gration tool to isolate specific transactions within multiple legacy sys-tems and expose them as reusable com-ponents and Web services. To become a real-time enterprise, follow these SOA 2.0 best practices:
• Implement enterprisewide: Any advanced SOA should extend through-out the enterprise without being lim-ited to any particular platform or technology. This must include legacy mainframes.
• Implementasingle,unified,bus-likeplatform: An enterprisewide SOA implementation entails a distinct departure from point integration sys-tems, involving a comprehensive Web services-centric platform that acts as a foundation for a distributed SOA approach to messaging and integra-tion in the form of an Enterprise Service Bus (ESB). The heterogeneous mainframe-reliant enterprise also must incorporate into this model all mainframe connectivity—a main-frame services bus approach—where data, applications, or business logic are seamlessly available via industry stan-dard technologies.
• Seekeaseofdevelopment: An oppor-tunity to harness the power of publish-ing a given event as a Web service is self-defeating if the custom develop-ment required is too time-consuming. So, the real-time enterprise should have a comprehensive IDE with an intuitive graphical interface. It should be able to leverage modern application development frameworks for .NET and Java as well as provide seamless integration to expose mainframe appli-cations and data as Web services and consume Web services from distribut-ed platforms, real-time business events, or as direct SQL calls. The ideal is to have a single development environ-ment to handle any integration require-ment without requiring detailed knowledge of the mainframe or dis-tributed technologies.
• Balance security and optimum per-formance: The reach and flexibility SOA provides can potentially compro-mise security; this is particularly true on the mainframe platform. Mainframes just weren’t designed with the idea that a consumer might sign on via a button on a Website which would activate a Web service that might hit that mainframe a thousand times a day. A means of managing and reduc-
ing the processing overhead for authenticating loosely coupled con-nections should be implemented. For any process requiring authentication (e.g., a Web service or SQL call), this mechanism should work in conjunc-tion with the established client and host security protocols to optimize user authentication for sign-on pro-cessing.
• Maintain transactional integrity: Real-time events can provide a critical role in maintaining the consistency of data and process orchestration. Given the huge volumes of transactions in the mainframe portion of an advanced SOA, it’s essential that proper support is provided for Two-Phase Commit (2PC) and emerging requirements for Web Services Business Process Execution Language (WSBPEL) and WS-Atomic Transaction.
• Address maintenance, performance,and scalability: Simply having inte-gration without the ability to control it would result in a system lacking enter-prise quality of service. Implement capabilities such as real-time diagnos-tics to ensure resource availability. Performance and scalability, while intangibles, must be addressed.
For an example of advanced SOA and the applicability of real-time enter-prise approaches to business processes, consider the trading sector of the finan-cial industry, where so many variables can affect markets and where EDA has begun to be adopted to automate imme-diate reactions to changes in those vari-ables. Where the evolution of SOA can best accelerate productivity and effec-tiveness, though, is in scenarios where real-time processes have been lacking. For example, consider the insurance and finance division of a large company in any unrelated industry sector. Say this division is running a homegrown legacy benefits administration system on a mainframe that handles health insurance and claims as well as 401(k) plans for tens of thousands of employ-ees. The company’s Website has a pass-word-authorized, log-in area that lets employees register, complete, and sub-mit forms, etc. Behind the scenes, how-ever, division staff members are re-entering all this information into “green screens” accessing the legacy sys-tem; they’re also identifying materials requiring further human interaction—such as underwriting verification, claims adjustment, and approvals—and rout-ing them to the appropriate parties. As
the available “Web services” increase, and as employees make greater use of them, more staff time is required for sorting and data entry. This organization is a prime candi-date for implementing a real-time solu-tion using an advanced SOA to service-enable their mainframe assets in a real-time fashion. The mainframe interoperability would be best served by middleware in the form of a single plat-form for handling data access (SQL), screen transformation into Web services, and mainframe business event manage-ment. The solution would provide a real-time bridge between the mainframe system of record and the distributed servers, running on Windows or Linux. Data existing on forms that require no further interaction could be written directly to the legacy application data-base via the middleware, while forms requiring review could be pushed asyn-chronously to the appropriate parties using a readily available shared portal software product. Inquiries made via the Web portal can seamlessly interact with mainframe green screen transac-tions that have been transformed into Web services. All application development needed to support this advanced SOA can be done via industry standard Microsoft .NET or Java tools, requiring no special-ized mainframe programming skills. Without having to tamper with its prov-en, strategic mainframe software infra-structure, the organization will now be able to rapidly transform its legacy sys-tem into a more flexible, Web services-based application that better addresses the current and future needs of its employees and that slashes the staff time spent processing employee data. This example shows the potential benefits of an advanced SOA when implemented with real-time enterprise best practices. The applications are vir-tually endless and the room for creative thinking is vast. With the addition of real-time events, SOA carries great promise for companies eager to seize the opportunities and competitive edge it affords them and points the way to the future of the real-time enterprise. bij
About the Author Chris Garner is vice president of research and development for DataDirect Technologies’ Shadow mainframe integration products. He has been on the front line of mainframe and data integration technologies for more than 30 years. Email: [email protected]: www.datadirect.com
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 6 1
Adapters enable reuse of existing applications and systems using
XML-based methodologies, providing an effective means of quickly integrat-ing Enterprise Information Systems (EISes). That need emerges often fol-lowing mergers and acquisitions. Adapters help organizations take a stan-dardized, consistent approach to inte-gration and facilitate service-based software initiatives.
Software Services Software services are a method through which another software entity reuses existing software functionality, not by “cutting and pasting” the source code, but via a run-time, requestor-server model. The new software entity that lacks the necessary functionality calls an existing software entity that has the functionality to execute the task on its behalf. This task most commonly includes specific transactions with clearly defined inputs, supplied in the request, and expected outputs. By enabling one software entity to provide the required functionality as a
“service” to other software entities, enterprises can leverage proven applica-tions. This reduces development sched-ules and testing requirements, minimizes the risk of errors, and sup-ports faster and greater ROI.
Adapters An adapter is a programmatic back-end connector that links various types of EISes, including packaged applica-tions, transaction processing monitors, message queuing systems, legacy appli-cations, databases, and file systems. Adapters adapt one set of software to answer the needs of another set, in a transparent, non-invasive manner, with no changes required to existing applica-tions. This usually occurs by leveraging strategic transactions, data or program-ming logic associated with existing applications for quick, easy reuse in new software. The adapter first captures and defines a transaction or a data structure from an EIS as an XML schema, then creates a representational object, such as an Enterprise JavaBean (EJB) or a Microsoft .NET assembly, or a standard
XML Web service (using a plug-in, if necessary) for reuse by other software entities. Adapters provide two elements missing from standard Application Program Interfaces (APIs):
• A self-describing container that tells the requestor what the function does, expects, and sends back
• A standard method of returning data regardless of the system being con-nected.
Service-Based Software Initiatives Adapters facilitate service-based software initiatives by creating paths between the caller and existing applica-tion (server) for effective communica-tion and integration in a standards-based model. The adapter doesn’t only create the object that represents a transaction or a data structure from the existing EIS; it ultimately provides the connec-tion that lets another EIS reuse the functionality. If the object represents a transaction, execution of this task requires the adapter to support the path of the call from the caller to the appro-
6 � • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
Laying the Foundation for Enterprise Software Initiatives
Bidirectional, Pure Play Adapters
By Archie Roboostoff
priate service. If the object is represen-tative of a data structure, the adapter is needed to provide the path through which the data structure can be accessed or updated. As the bidirectional, back-end inter-faces to existing EISes, adapters provide seamless application integration using today’s universally accepted XML-based software services methodology, used in Service-Oriented Architecture (SOA), Web services, and the Enterprise Services Bus (ESB). Developers can quickly, easily access and use requisite software functionality in EISes without any new coding or extensive knowledge of the EIS itself. Bidirectional, pure play adapters maximize developer produc-tivity by accelerating development schedules, reducing testing require-ments, minimizing errors, and enhanc-ing ROI.
Criteria for Effective Adapters Since adapters act as crucial bilateral intermediaries between new and exist-ing software, their capabilities, through-put, reliability and efficacy will determine performance of the new soft-ware. So they must meet the following baseline requirements to be able to sup-port the dynamics of contemporary, strategic service-oriented software development or BPM orchestration projects:
• Standards compliant, with a clean,openarchitecture: A pure play adapt-er is completely standards-based and written entirely in Java or C#. They work natively in an application server, Web server, stand-alone Java Virtual Machine (JVM) or a .NET environ-ment, without requiring any proprie-tary layers, such as proxy servers or integration servers. This independence enables faster, more effective perfor-mance and greater scalability for ser-vice-oriented software projects.
• Bidirectional support for synchro-
nousandasynchronous interactionsinandoutoftargetEISes: This means that every interaction with a target EIS (e.g., SAP R/3) doesn’t need to be initi-ated by the adapter’s client software. Unsolicited calls from the EIS to the client software can also be automati-cally triggered based on schedules or predefined EIS-related event (e.g., a record being updated or a transaction being executed). The ability to auto-mate interactions in this manner enhances reliability, efficiency and cost-effectiveness.
• Support for all relevant EIS APIs: Both packaged and legacy applications often offer multiple client APIs to accommodate different levels and types of access. Adapters should sup-port all the most popular APIs, such as those provided by SAP/R3, PeopleSoft, Oracle, IMS, and Lawson. The range of availability of APIs for different EIS interactions ensures high performance, scalability, and reliability.
• XML-based metadata capture: An advantage of contemporary pure-play adapters is that they can leverage the metadata available in the EIS to capture the necessary transaction I/O and data structures in an XML schema during the development and configuration phase. The developer doesn’t need to manually create these parameters, but can use the adapters to cut and paste the XML into an application as desired, greatly reducing human error and development time. Consider an exam-ple: A Web developer wants to create a new application that gathers data from SAP and Siebel, is using standard APIs, needs to determine which fields in SAP and Siebel are mandatory, requires date structures, needs to be string format-ted, etc. An adapter would describe these inputs and outputs in the meta-data, so the developer would know this information.
• Intuitive, visual access to EIS func-tionality: Adapters should provide
back-end interfaces to EISes and sup-ply developers with intuitive, visual representations of all EIS transactions and data. The developer gains a com-plete understanding of the nature and properties of all transactions and data structures, ensuring efficient develop-ment with a lower risk of errors.
• EasycreationofnestedWebservices: Adapters facilitate Web services by creating nested Web services, which are Web services made into another Web service for reuse by another appli-cation. This eliminates the need to create new schemes to access the orig-inal Web service, giving developers direct access to and reuse of existing services.
Conclusion Adapters act as the governing factor for the capabilities, performance, reli-ability, extensibility, and scalability of new services-based software. New soft-ware services may be created using sev-eral approaches—SOA, ESB, Software as a Service (SaaS), Enterprise Data Access (EDA), plain XML Web services, a composite application, portlet, cus-tomized front-end, Business Activity Monitoring (BAM) dashboard, or a Business Process Management (BPM) orchestration. Regardless of which method is chosen, adapters remain the key component that captures and cre-ates the most fundamental piece of all such initiatives: reusable, XML-centric software services. Developers can sys-tematically, effectively, and securely integrate the old with the new, using standardized integration adapters. bij
About the Author Archie Roboostoff has more than 10 years of experience in the high-tech industry, focusing extensively on adapters and enterprise information integration solutions. Currently, he’s responsible for product management at NetManage, Inc.Email: [email protected]: www.netmanage.com
B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6 • 6 3
BuSInESS • Adaptersmaximizedeveloperproductivitybyaccelerating
developmentschedules,reducingtestingrequirements,minimizingerrors,andenhancingROI.
• Adaptershelporganizationstakeastandardized,consistentapproachtointegrationandfacilitateservice-basedsoftwareinitiatives.
TEChnOlOgy • Integrationadapters,inherentlyXML-centric,areideallysuited
architecturallyandfunctionallytoserveaskeyfacilitatorsinservice-basedsoftwareinitiatives.
• Whenusingadapters,thefunctionalcapabilities,throughput,reliability,platformpreferencesandefficacyofexistingsoftwaredeterminesperformanceofthenewsoftware.
• Integrationadaptersareideallysuitedtoserveaskeyfacilitatorsinservice-basedsoftwareinitiativesandcanbethedeterminingfactoroftheirscopeandsuccess.
6 4 • B u s i n e s s i n t e g r a t i o n j o u r n a l • n o v e m b e r / d e c e m b e r � 0 0 6
once upon a time, in the near future, Mike, CEO of Anybank, was getting worried. Customer retention rates
were below plan and profitability of the Professional Dual-Income (PDI) segment was slipping fast. This group of customers had historically been a bellwether indicator of market trends and an accurate predictor of overall business profitability. Mike adjusted the U.S. GDP projections on his business simulator to the high end of the economic forecast—the results didn’t look much better. Next, he raised the terrorist threat risk to orange and softened the Competitor Aggressiveness Index. Still no good. Mike was convinced his chief marketing officer was right on target—the latest PCA (Personal Communication Assistant) was taking the market by storm. Mike had to admit the new PCAs were amazing. His kids loved them and even the dog had one on his collar. The combination phone, video, music, and universal life recorder with its terabyte storage, GPS, and continuous connection to the Internet was catching on fast. Mike spoke to his Smartphone, “find Christine.” Christine was Anybank’s CAO (Chief Architecture Officer), who Mike had lured away from one of the big-five consulting firms a few years ago to transform his organization into a more nimble market leader. A few seconds later the response came: “Christine Smith is at a conference in Boston and enabled for priority-two calls.” Mike replied: “Establish video link.” After a short pause, Christine’s image appeared on the wall-screen. The image was a bit jerky as she walked down the hallway. “Hi, Mike,” she said, “my session just ended and I’m heading back to my room—what’s up?” “The PDI early adopters are deserting us in droves,” Mike quipped. “Google-Bank’s gamble to aggressively promote the PCA integrated with their Online Marketplace looks like it’s paying off for them—at our expense. The projections coming from the business simulator are showing bottom-line losses for us in just about every scenario unless we can react fast. Any ideas?” “I’m not entirely surprised,” responded Christine, “the scuttlebutt here at the conference is that Google is gearing up to fuel the flames with yet another marketing wave. But we can do something they can’t—we can move faster. You remember the Agile Operating Model we began implementing 18 months ago?” “How could I forget; it cost enough,” Mike said. “Well, all the core business services are in place and enabled for internal operations and for our tier-1 suppliers,” Christine explained. “And with our Customer Decision Rules Engine we can implement new test strategies overnight. With your support, I’ll call an emergency meeting of the Customer
o n c e U p o n a t i m e
B Y j o H n s C H m i D tt H E s o f t W a r EE C o Lo G i s t
Decision Strategy Team tomorrow and we’ll hash out three or four strategies to test market. A couple of the strategies could involve various PCA giveaways, while the others could tweak the loyalty points or promote a bundled offering. We could take about 5 percent of the PDI customer segment, divide it up across the strategies and test them all at the same time. Within two weeks we’ll have the hard data we need to tell us which strategy is most effective against the Google threat. Once the strategy is confirmed, we can bring the marketing and customer service teams into the tactical development plan and immediately roll out the programs.” “Are you serious?” challenged Mike. “Can we really react that quickly with the new operating model?” “Absolutely,” confirmed Christine. “I’ve been waiting for the day when our investment in technology pays off with a happy surprise,” said Mike. “You’ve certainly made my day. Go for it, Christine—and let me know if you run into any roadblocks with the Customer Strategy Team.” “Great. Thanks, boss,” said Christine. “I’ll give you an update as soon as the results start rolling in. Have a nice day.” Christine disconnected her PCA and smiled to herself. She was glad to have made her boss’s day and she had high confidence in the Service-Oriented Architecture (SOA) her team had built. Her years of training were paying off, and she was confident in the lessons she learned from her degree in Software Engineering and her master’s degree in Business Architecture. She also was grateful for the groundwork laid by the SOA Alliance. Two years ago, the Alliance planted the ideas for the new operating model with Anybank’s CEO and the rest of the executive team in a leadership retreat. It was that session which started the sequence of dominoes that led to the “happy surprise,” as Mike put it.
Epilogue: While this story is somewhat aspirational, there’s no “rocket science” required; all the technology and best practices exist and are in commercial use today. The most fanciful aspect may be that the leadership exists within organizations to pull all the pieces together into a unified strategy. For those that do, the fairy tale will become a reality. bij
About the Author John Schmidt is chairman of the Integration Consortium, a non-profit, leading industry body responsible for influencing the direction of the integration industry, and a founding member of the SOA Alliance. He is the author of Integration Competency Center, the first book in the industry that provides practical advice on implementing enterprise integration centers of expertise.Email: [email protected]
Call for Papers Now Open!Business-focused Sessions Accepted submissions will feature experienced presenters, practitioners and business leaders willing to share their knowledge and experience in leading business transformation and innovation. Submissions should be business-focused, presenting experience executing the strategies and solutions surrounding business transformation initiatives, as well as the lessons learned from internal programs and technology deployments. Suggested topics include:
• Transforming Business Processes From Innovation Obstacles to Innovation Enablers
• Beyond BPM: Process Optimization and Business Performance Management
• Effective Compliance and Governance Strategies • And other applicable topics.
Technology-focused Sessions Accepted submissions should feature CTOs and Chief Architects discussing leading development strategies. These sessions are intended to present a peer-to-peer forum to showcase thought leadership, allowing developers and architects to engage in a competition of ideas and experience. Sessions featuring marketing staff or product-focused presentations will not be accepted. Suggested technology topics include:
• Leveraging Open Standards and Open Source Software• Defining an Effective Information Architecture• Delivering Composite Applications Using AJAX and SOA• And other applicable topics.
Submit Your Paper Today at:www.transformationandinnovation.com/pages/papers.php
May 21-24, 2007Hilton Washington
Dulles Airport
