Operationalizing SOA

» GIF and you shall receive

The one thing that I find consistent in any customer IT environment working with SOA is heterogeneity. Whether it pertains to runtime platforms, intermediaries – ESBs and appliances, development tooling or back-end applications, there are almost always more than one.

SOA Governance offers the promise of visibility and control but only if it can work with and enforce polices across heterogeneous infrastructure. To that end, the industry needs interoperability efforts with teeth. Not just press release-only relationships (otherwise known as Barney relationships) but real collaboration where vendors work together to achieve integration and interoperability based on standards that can be shared and replicated across a variety of infrastructure.

HP is driving one such effort called the Governance Interoperability Framework. We invite all industry vendors working on pieces of the SOA puzzle who want to participate in this domain called governance to take a look at the GIF spec and participate in the GIF community.

Just don’t take my word for it, check out the recent blog by industry expert Anne Thomas Manes at http://apsblog.burtongroup.com/2008/03/hpsystinet-fina.html

You can access the GIF spec at HP.com at www.hp.com/go/soa

» Quick thoughts – SOA, Web 2.0 and Wall Street – a legitimate mashup?

This week, I was sloshing through the sleet and snow of New York City (still a fabulous city no matter what the weather) to attend and present on a panel at SOA on Wall Street (also so named Web Services on Wall Street). I participated on the opening panel which took a look at Web 2.0 and SOA and its implications and relevance for Wall Street organizations.

In a nutshell, Wall Street needs SOA and situations like Societe Generale are making it more urgent. I also believe Wall Street can benefit from the “wild and wooly” world of Web 2.0. Perhaps not for their mission critical infrastructure that requires the highest levels of performance, operational integrity and security, but definitely for collaboration, encouraging innovation between department and teams and non-critical information syndication. However, I disagreed with one of the panelist members who made a statement that SOA capacity is hardly realized so we should not worry about the governance or operational concerns and focus our energy on fostering innovation. I believe the time is now for all organizations, financial services and otherwise, to plan for and work with SOA governance, as well as SOA quality and management, to build out the infrastructure and best practices, so that when they find that “killer composite application” or that viral Web 2.0 service, they are prepared for the onslaught of new consumers, the load and performance implications, the version management challenges and can support innovation at the speed of business with the rigor of operational IT.

For the last two years, it seems organizations have focused around the need to modernize the middleware infrastructure to support SOA. Firms have been investing in ESB, BPM and data services and building out integration, data and some business-level services for use in composite applications. Now banking and FSI is primed for the embrace of Business-Technology Optimization for SOA -- governance as well as quality and management. These companies are going to run into all the visibility and trust issues the industry analysts discuss about SOA Governance by just focusing their architecture, development and delivery teams on the ESB and integration layer without thinking about how they will foster service visibility, consistency, policy management and service consumer management.

That said, I think the Wall street front office is probably the most challenged in embracing SOA right now as the focus has been on performance, data integrity, security, operational resilience and performance (did I already say that?). But that doesn't mean a Wall Street firm is not ready for SOA. During the conference we discussed a lot about the need for SOA in the middle office to help with innovation, research, new customer offerings, and to avoid situations like Societe Generale through visibility, trust and control.

It doesn’t matter where SOA is happening (front, back or middle) it will need governance.

For companies that don't have appetite yet for full-scale governance, something like HP’s newly announced Governance Validation service is a great entrée… Think big and start small -- take a domain or single project and implement a focused governance implementation for a contained set of services and then scale when ready. With this approach you can immediately see measure able benefits without a large initial cost (assuming you have a clear organizational owner and roles defined for governance – worth another blog)

There is a place for SOA and Web 2.0 on Wall Street – in the middle office or anywhere where agility and collaboration are paramount. To hear more about the insights shared at the event, see the event page at: http://www.webservicesonwallstreet.com.

» Emo's SOA World -- All I really need to know about SOA, I learned in Kindergarten

[Source: "ALL I REALLY NEED TO KNOW I LEARNED IN KINDERGARTEN" by Robert Fulghum. See his web site at http://www.robertfulghum.com/ ]

Metaphors are magic. IMO, they help people grok (wikipedia: http://en.wikipedia.org/wiki/Grok) complex subjects and make them understandable. This year, I’m experiencing a right-of-passage as my youngest has entered Kindergarten. That being top of mind, it brought back to me the well-known prose from Robert Fulghum’s “All I Really Need to Know I Learned in Kindergarten”. He made the statement about the message in his book:, “Take any one of those items, (from his list of everything I really need to know I learned in Kindergarten) and extrapolate it into sophisticated adult terms and apply it to your family life or your work or government or your world and it holds true and clear and firm”.

I thought to myself how would this concept apply to the domain of SOA Best Practices? Here’s my attempt to apply the metaphor -- “All I’ll need to know about how to successfully implement SOA is there to be learned in kindergarten. SOA Success is not at the top of the Enterprise Architecture Mountain, but there in the sand pile at school”.

These are the things I learned:

• Share everything – I’ll take a slight derivative of this, “learn to share”. This statement doesn’t mean re-use everything but it does imply that you need to ensure the infrastructure, processes and corporate culture is built to encourage sharing, not penalize those for it. This maps to adopting SOA processes and technologies that deliver visibility, trust, a culture of shared benefit and shared costs and favorable cost models (avoiding “not in my budget”)
• Play fair—Allocate costs accordingly, put in measures to encourage good SOA practices (reporting and dashboards help) and understand the implications of change and how people and culture must change as well to accommodate SOA.
• Don't hit people—Corollary to the above, do not penalize the first SOA project for being over budget. SOA will initially cost more but then the rewards come with subsequent projects when the benefits of agility, trust and potentially re-use kick in. This first project should not be penalized for investing in “good, clean SOA”
• Put things back where you found them – This is a biggie. SOA governance is critical here. We need to avoid rogue services. Services and their associated artifacts should be effectively catalogued and changes should be managed and reflected as such. If you “move” a service (such as redeploy it to a more scalable platform), update the catalog so consumers can find the change. This simple rule will avoid SOA chaos and web sprawl.
• Clean up your own mess—Key to SOA success is measurement, reporting and accountability through a service lifecycle. A successful SOA includes having the capabilities to visualize the SOA in action, proactively monitor and measure service interactions and performance and feed that information back into the SOA catalog or system of record so that changes can be made to “clean up any messes” and ensure SOA health, stability and availability on an on-going basis.
• Don't take things that aren't yours—This comment may first seem to contradict the concept of re-use but I looked at it a different way. A successful SOA is a Governed SOA. Governance allows services to go through a process of understanding how they should be re-used, and who has authorization to re-use services. A successful SOA supports this concept and enables policies to ensure that services are accessed and used in ways that support the business objectives and not endangered by rogue consumption.
• Say you're sorry when you hurt somebody—I interpret this one from a SOA perspective as building into the SOA process the ability to apply governance at all stages of the SOA lifecycle and to be able to proactively manage when services fall out of compliance. You cannot determine whether a SOA action is helpful or harmful without comprehensive governance across the lifecycle. .
• When you go out in the world, watch out for traffic, hold hands and stick together—And when you go out into the SOA world, set yourself up for success. Ensure that core to your SOA effort is management and visibility (watch for traffic), Ensure that your processes and organization are designed to “hold SOA hands”, in other words, encourage the creation of shared services and all the implications of that (shared costs, upfront complexity for downstream benefit, participation in the governance process). And finally, align business and IT across the SOA goals (stick together) and this is worth another blog…. .

Successful SOA is more than just creating and integrating standards-based services. It requires organizational and process changes to support sharing of code, costs, and information. It requires effective governance to ensure that services are compliant to corporate and IT objectives, services are visible for re-use and services can be trusted. It requires management to ensure that the in-production SOA results map to customer SLA and SLO expectations regardless of how the landscape changes, and it requires alignment of the business and IT towards common goals and expectations so that the SOA effort pays off in business terms now and in the future to become “not just another IT experiment” but truly an element of strategic business transformation. More on that in another “Emo’s SOA World”.

» Kelly Emo's World on SOA

Welcome to Emo’s World on SOA. I’ve been on a professional journey for the last eight years with SOA, and some would argue even before that time while working on technologies such as CORBA and DCE (does anyone remember the Distributed Computing Environment?) .

Through the years, I’ve been getting my hands dirty with SOA from the chaotic “new economy” days of early 2000 while attempting to build innovative ASP (another legacy buzzword—Application Service Provider) solutions through harnessing Web Services (can we say point-to-point?), to attempting to creating a more agile IT infrastructure for SOA by leveraging the concept of an intermediary, getting on the “bus” to implement SOA if you will. During the last few years, I’ve seen first-hand the short-term benefits of investing in infrastructure but also the sticky longer-term challenges – where projects get stalled or fail due to a singular focus on the foundation without the planning and investing in the governance processes, operational management and other key success factors to realize a true working SOA that delivers rewards to the business.

After working with a wide array of customers and partners in this space over the last several years, I plan to share real-world examples and anecdotes of best practices for taking the next steps to SOA success, not just through infrastructure but true SOA deployment and operations with tangible value.

Through my blog, I’ll be taking you on a journey to explore and debate what capabilities and best practices are needed to realize measurable business value from SOA efforts while leveraging investments in SOA enablement such as integration suites, application servers and ESBs. I also plan to tackle some controversial subjects such as “an ESB does not a SOA make” or “When is an org not ready for SOA?” Come along, it will be an interesting ride…

» Title: Accelerating SOA Success through Domain Models

Content:

Our user conference (HP Software Universe) was last week in Barcelona.

There were many discussions of SOA, as you would expect. Pawel Maszczyk presented his experience with SOA. The Carphone Warehouse, who has grown 500% over the past five years to have approximately £4B in revenue, has been deploying SOA over the past two and a half years. The business believes that SOA has been a successful initiative because they have seen two business results: a dramatic increase in IT’s ability to respond rapidly to change; and a decrease in cost for IT projects.

One thing that struck me about Pawel’s presentation is that he believes successful SOA adoption can be accelerated significantly. Carphone Warehouse has built their SOA essentially on their own – no extensive involvement of any consulting company or vendor. As they started building and deploying SOA services and composite applications, they addressed issues as they arose. They have now organized all the issues into a seven-part domain model, including projects, building blocks, architecture, business processes, organization, governance, and financial model.

By taking each of the first six domains into consideration at the beginning of a SOA initiative, companies should be able to reduce the challenges that occur during service and application development.

Carphone Warehouse built their domain model as they went through the process of deploying their architecture, essentially putting the model together as they went. HP’s Consulting and Integration practice has an eight-part domain model (business, people, program management, governance, architecture, enabling technologies, operations and management, and supply & demand); the high degree of overlap with Carphone Warehouse is a good thing.

What domain model do you use? How many parts are there?

» What are the practical challenges of reusing services?

» The rules of the blog

The rules of the blog are simple and pretty standard. Please adhere to these policies.

» Welcome!

This is a special blog that combines the input from many of the SOA product and services experts at HP Software. Our team here is dedicated to helping you get the most out of SOA. We concentrate on a specific set of challenges that SOA presents.