Going Right to the Source

July 21st, 2009 by Kyle Gabhart

In-source, out-source,
up-source, down-source,
crowd-source, cloud-source,
source, source, source.
At your work and on the street,
how many different sources you meet!

(Inspiration borrowed from multiple readings of Dr Seuss’s The Foot Book to my toddler).

It seems everyone these days is looking for a new ’source’ for making their business, civic organization, or personal life more efficient and/or more manageable. I see two primary motivations for this trend:

There is a seductive and ever-strengthening pull to join “The Cult of the New”
There are genuine market pressures as well as social and economic dynamics that are solved by optimizing resource utilization

At this point, I am tempted to just end the discussion here and farm (code for ’source’) the rest of this post out to the blogosphere and let all of you solve it (I’m a fan of irony). But I think I’ll go ahead and expend a few more brain cells and actually try and make a coherent argument of my own first.

The Cult of the New

If a technology, methodology, or other ‘-ology’ has two or more of the following criteria: shiny, has acronyms associated with it, has a magazine with the name in the title, has a conference dedicated to it, etc., then it is ripe for hype and for drawing people toward it out of the sheer momentum that it is THE thing to do!

The momentum around ’sourcing’ and in particular, cloud-sourcing certainly falls victim to this in many respects. It is important to realize that the problems we have today as well as the solutions to those problems largely remain the same. It’s not to say that there is nothing truly innovative, but it is to say that often times we repackage or even just rediscover a way of solving a problem and it is simply called something different or is applied at a different level of abstraction than it was when it was originally introduced 20 or 30 years ago.

There are genuine opportunities around sourcing / farming / distributing work across various resources. But there are also real-world risks associated with doing so. I’ll be exploring both of these themes in a webinar tomorrow afternoon. (Wednesday - July 22nd starting at 12PM EDT) - “Risks and Opportunities with Cloud Computing” I hope you are able to join in.

Resource Optimization

I certainly don’t want to give anyone the impression that sourcing needs out or offering capabilities in a flexible, distributed, even utility service fashion is necessarily a bunch of noise. I do believe that there are genuine market pressures and economic realities that drive organizations of all shapes and sizes toward some sort of creative sourcing model. Bruce Barnes supplied an excellent analysis of this in a CIO Update article earlier this month - “Smart Sourcing: The New Normal”. Bruce focuses upon effective vendor / partner management in this new world of smart-sourcing and he outlines 6 steps of managing this effectively.

In addition to effective vendor management, there are some essential steps that must be taken internally within the organization in order to truly manage resources and the sourcing of work effectively. It all begins by taking several giant steps back and evaluating your business drivers to ensure that you are pointed in the correct direction to begin with. From there, you must embark upon a process of discovery around internal needs and capabilities, external resources, provider service levels, resource utilization metrics, and comprehensive enterprise portfolio management.

If adopting a cloud computing or similar multi-sourcing model of problem-solving is something you are considering, you may want to take a look at a post of mine from earlier this year (Adopting Your Very Own Cloud) where I explore pragmatic steps for evaluating and potentially adopting such an approach.

Posted in Cloud | No Comments »

Juggling Multiple Data Models with Services

March 3rd, 2009 by Kyle Gabhart

Recently, a client approached me with a quandary. When designing XML schemas for Web services, how do you balance the desire to use industry standards such as UBL ( Universal Business Language) or CICA ( Context Inspired Component Architecture) to support data interoperability with the unique needs of particular domains and sub-systems within the enterprise? The client’s service design team is rightfully concerned with the competing interests of internal enterprise standardization, interoperability with external entities, and addressing the unique needs of local domains and process constraints. How can these competing needs be effectively managed when designing the schema for a given service?

The Standard Answer

Naturally, you start by giving the standard answer - “it depends”. This is an essential and carefully crafted phrase that all consultants are taught to give according to page 17 of How to Win Clients and Influence Budgets. Of course, the standard answer is rarely sufficient, but it is not without merit. It is certainly true that the decision regarding your data model design depends significantly upon a host of factors:

Which use cases are high priority?
Which use cases are high impact (to stakeholders and/or to customers)?
Which systems and/or processes are mission critical?
Are you including industry standard data models in you enterprise out of necessity (i.e. ONLY when you are forced to interact with other entities), or is it part of a broader modernization effort within your organization?
Do interoperability challenges or integration challenges currently contribute most significantly to your development and/or maintenance costs?
Which interaction scenarios are of higher priority, internal or external service calls?
Would aligning more closely to one of the available models lead to a significant reduction in data mapping activities or is the environment simply too fragmented to support this?
Is there one particular system or business process that is unique and skewing perceptions regarding our service data models?

While all of these questions (and many more) are important and aid in facilitating a thorough examination of the problem, we rarely have the time to examine each problem from all possible angles. Consequently, we must look toward guidelines and rules of thumbs.

Guidelines for Managing Multiple Service Schema

1) Your business processes should only work with a single data model if at all possible. Business processes are best designed to be data model agnostic and operate off of an internal, process-centric model. I explained the importance of process-centric data models in a previous post.

2) Your services should work with as few data models as possible (one model being preferable). This is just good commonsense. For each data model that is added to the mix, your development time and long-term maintenance costs increase at a non-linear rate. The pain will intensify and it will do so rapidly with each new model you add to the mix.

3) If your services are going to work with multiple models, you should put some sort of taxonomy / categorization scheme in place to distinguish the data models used by services. For example, services that are outward facing might use a data model accepted more broadly by the industry. Services used by a particular LOB might use a certain data model, and services used by another LOB might use another. Another distinction could be infrastructure services vs data services vs application services. Regardless of the approach, there needs to be some methodology that is objective and governable for when one data model is used vs when another data model is used.

4) Data model transformation is a necessary evil. It should be done only when necessary and you should contain the transformation to a designated component. Transformation activities should be handled by intermediaries (data services, ESB, network appliance, other mediation framework) when possible rather than building it into the internals of a service or process. This keeps your services clean, provides a nice reusable transformation mechanism, keeps your interoperability more loosely-coupled, and provides for agility and extensibility in the future.

Juggling multiple data models within a service oriented environment is no one’s idea of fun. When possible, aim for a more comprehensive and strategic analysis of the environment (see the ‘Standard Answer’ outlined above). When this is not realistic, try to use the above guidelines and rules of thumb to help you tactically navigate the murky waters of data model incongruity. Service design isn’t easy, but it doesn’t have to be rocket surgery either. Best of luck!

SOA SOA Expert SOA Data Modeling SOA and MDM MDM Canonical data model Service design schema design SOAD

Posted in SOA | No Comments »

SOA’s not dead yet…it’s getting better

January 7th, 2009 by Kyle Gabhart

All across the blogosphere, analysts, experts, and technology enthusiasts are buzzing about the latest claims that SOA is dead. The thunderstorm of controversy was set off by Burton Group analyst, Anne Thomas Manes, who recently blogged an obituary for SOA entitled: SOA is Dead; Long Live Services. As I consider the bold claim of SOA’s death and square it with the dozens of clients that I have worked with on various service orientation initiatives throughout 2007 and 2008, I can’t help but think of the “Bring out your dead” scene from Monty Python and the Holy Grail. I can just hear the personification of SOA pleading with Miss Manes: “I’m not dead yet…..I’m getting better.”

The ‘obituary’ begins as follows:

“SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.”

Manes goes on to describe SOA as a “failed experiment” in which some companies invested millions with almost nothing to show for it. In fact, she states, in some cases the enterprise is in a worse state:

“In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.”

Throughout the interesting and entertaining read, the post makes four essential claims:

SOA did not live up to its promises
The term ‘SOA’ has a negative connotation and evokes backlash
The need for services and service orientation is stronger than ever
Success requires transformation

Claim #1: SOA did not live up to its promises. I’m not sure exactly what SOA promised, but I am well aware of what many CIOs/CTOs promised their boards and I am well aware of what various vendors and consulting organizations promised. Each of these groups had their own agendas and motivations, but the result was the same. They made outlandish promises and viewed SOA as some sort of magical panacea. So the problem is with the expectations that were lumped in with the term ‘SOA’, and not with the actual viability of an architecture that is service oriented. This naturally leads us to the next claim regarding terminology and backlash.

Claim #2: The term ‘SOA’ has a negative connotation and evokes backlash. In my experience, this is fairly isolated within particular companies and not representative of the industry as a whole. Anywhere that a CIO/CTO, consulting company, or vendor has run amuck has resulted in associating negative things with the term ‘SOA’. Moreover, I have worked with multiple organizations that openly refer to their initiative as SOA. I highlighted 36 companies spread across 5 market sectors with SOA success in my book. Finally, Joe McKendrick has kept a running commentary on his blog each December highlighting SOA success stories.

Claim #3: The need for services and service orientation is stronger than ever. Building off the frustration with the term ‘SOA’, Manes states: “Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.” She cites cloud computing, SaaS, and Web 2.0 mashups all as examples of the need for services and service orientation. It appears that her real beef is again with the term SOA and yet much of the article is spent talking about how SOA is out, yet services and service orientation are in. The trouble is that if you develop cloud services or web mashups without an architecture that is service oriented, what hope do you have of success? If service orientation and services are indeed essential, you need a comprehensive architecture to support such efforts.

Claim #4: Success requires transformation. Amen sister. This is so true. Anne says that the secret to SOA success comes down to a real commitment for transforming the organization and that SOA is only one part of that broader enterprise transformation. She eloquently describes the importance of this commitment when she states: “If you want spectacular gains, then you need to make a spectacular commitment to change.” So true.

What’s in a name?

A key theme throughout all of this is that the term SOA may carry with it some unfortunate baggage. I appreciate this point quite well. I made a plea to consultants and analysts last year as a panelist at the Open Group’s EA conference in San Francisco and then again via this blog (A Rose By Any Other Name) regarding the need to move past these labels and focus upon true transformation and problem solving. In the end, if we aren’t improving organizations and moving enterprises forward, then we’re just peddling the “next shiny IT thing”.

The case for a bright future

Disappointment regarding SOA’s ability to live up the hype and frustrations over terminology aside, I believe that the future for SOA is truly bright. Services are here to stay. Spin-offs such as SaaS, Web 2.0 mashups, and Cloud Computing confirm this reality. Service orientation is necessary, but not sufficient, for success with any of these initiatives. True success for enterprises deploying non-trivial service-based solutions must be backed by an architeture that is service oriented in nature. Dare I say…a service oriented architecture. Moreover, the maturity in the industry regarding SOA methodology, best practices, and tool support is at an all time high. Is SOA dead? Hardly. In fact, I’d say that it’s getting better.

SOA SOA Expert Cloud Computing SOA is dead Web 2.0 SOA adoption SOA success Service Orientation SOA Methodology

Posted in SOA | No Comments »

Is our SOA learning?

December 12th, 2008 by Kyle Gabhart

On a South Carolina campaign stop in January 2000, George Bush asked the immortal question: “Is our children learning?” Then again seven years later, Bush told a group of New York school children: “Childrens do learn.” YouTube video of both statements is available here. So I ask the question: Is our SOA learning?

As I think back on the SOA engagements that I have been involved in throughout 2008, the importance of education and skills development becomes crystal clear. I’ve blogged on the subject of SOA education many times. Of course others within the industry have also seen these challenges:

Sober SOA (Chuck Allen)
Re-think your SOA training strategy (Ronald Schmeltzer)
IBM survey reveals SOA skills gap (Lorraine Lawson)
Which will kill SOA fastest: no money or no skills? (Joe McKendrick)

At first glance, SOA education seems to be a fairly straightforward affair:

Get a couple of smart IT folks and have them do some research and self-education
Select an ESB vendor after detailed analysis and proof-of-concept work
Buy a block of training from your vendor
Implement SOA and rake in the ROI

The reality of the matter is a bit more complicated than this, however. SOA education must emphasize alignment with business drivers, effective governance, comprehensive solution methodology, and the development of new technologies and solution patterns. Vendor-specific training, while helpful, should come much later in the process, after there is a clear vision regarding service orientation and one or more vendor solutions are selected in alignment with that enterprise vision.

Complete SOA education

Rather than an ad-hoc training approach or one in which personnel are simply expected to “pick it up”, SOA education must be approached from a wholistic perspective. Complete SOA education involves three key elements: methodology, governance, and technical skills, all of which must be properly aligned with the organization’s business drivers and hence the ultimate motivation for enterprise SOA adoption.

In my next several posts, I will explore each of these three aspects of SOA education in more detail. Until then, feel free to get a high-level understanding of these concepts via a whitepaper I recently wrote with two of my colleages at Web Age — “SOA Training ROI”.

UPDATE: Joe McKendrick noticed the post and wrote about it here. In addition to having a great sense of humor, he also pointed out that Gartner had noted the lack of SOA skills and expertise in a report as recently as November.

Posted in SOA | 1 Comment »

Service Design - Are You A SOA Poser or a Com-Poser?

June 19th, 2008 by Kyle Gabhart

Up until now, there has been such a rush to roll out initial SOA services and supporting infrastructure, that little attention has been given to what good service design truly entails. This is a natural evolution that must occur with any technology or methodology. Throughout this summer, I plan on releasing several posts regarding proper service design.

Initially, I would like to focus on the subject of ‘composability’. Composable services have several important qualities:

composable services stictly adhere to their service interface, Service Level Agreements(SLAs), and supporting metadata
service operations always leave enterprise data in a valid business state
service operations can be called indepently, in parallel, or as a part of a larger service orchestration
service operations can be called within or without a transaction context

When you boil it down to the essentials, composable services clearly define what they do and they do exactly what they have defined. Consumers of composable services are then at liberty to determine how they want to use that service’s operations, rather than the service having certain built-in assumptions regarding how the service will be used or what the larger business context ought to be.

To learn more about the merits and details of composable services, I recommend the following resources:

“Composable Services” (MSDN Library)
“Service Composability” (SOAprinciples.com)
“A Composable Service is a Good Service” (Presentation at SOAWorld 2008 next week)

There’s another, less tangible benefit of composable services — they are lower stress. The frustration and stress associated with consuming a service that later fails due to some unknown buisiness logic violation is supremely frustrating. Consuming services that are not composable is stressful, because they cannot be depended upon to work in whatever context you choose. Likewise, publishing non-composable services for consumption is stressful because the service provider is constantly in fear that someone will ‘misuse’ a service. This is no way to run an enterprise or encourage the adoption of service orientation.

I’ll explore all of these topics next week in my presentation at SOAWorld on composable services. I’ll post the completed presentation as well as perspectives from the audience next week. Have a great weekend and I’ll see you in New York!

Posted in Conference, SOA | 3 Comments »

SOA World 2007 - San Francisco (Day 1)

November 12th, 2007 by Kyle Gabhart

The first day of SOA World 2007 - West went very well. Miko Matsumura with Software AG / webMethods kicked things off with the keynote - Time Oriented Architecture: Evolution by Design? And he had some really entertaining 3-D animation and virtual simulations in his presentation. It was pretty cool. The next presentation in the main room was by Theo Beack from BEA - Virtualized SOA: Adaptive Infrastructure for Demanding Applications.

I delivered the third presentation of the day in the main room - A Little SOA Goes A Long Way, discussing the importance of identifying which aspects of your enterprise are ripe for service orientation and which areas are better left alone. The outline for that presentation is as follows:

Introduction
Why SOA initiatives fail
What my kids taught me about SOA
Adopting SOA selectively
Bowling for governance
Review

This presentation seemed to be well-received and I was particularly pleased with the broad acceptance of the Selective SOA Methodology that I presented. This methodology serves as the cornerstone for much of the SOA Adoption and SOA Governance mentoring that Web Age Solutions provides to clients. If you’d like a copy of the presentation, you can download it here — A Little SOA Goes A Long Way (PDF).

After a trip to the Expo Floor and some snacks, we were back in the main room to hear from Mike Pellegrini from Active Endpoints presenting - Your SOA Needs BPEL For Orchestration. He had some great content, but one nugget really stood out to me early in the presentation. Mike was describing services and processes as two kinds of abstractions that are important in SOA. After discussing them separately, he offered the following synthesis: “Services don’t change often, but they are orchestrated and re-orchestrated fairly often to build/modify business processes.” I like that. I would qualify it to say that services SHOULDN’T change often. In other words, I believe that this is indicative of an enterprise that has reached a considerable degree of maturity in their service orientation. Nonetheless, I thought it was a really solid characterization of services and processes.

Following Mike’s presentation, the speaker that was slated to speak in the main room could not be located. After hunting for about ten minutes, SYS-CON got desperate and accepted my offer to deliver another presentation that I had on my laptop. So I hopped up on stage, grabbed a mic, and fired up my laptop with the same presentation that I had delivered at SOAWorld in June early this year in New York - Service Oriented Patterns and Anti-Patterns. Fortunately, I had delivered that presentation about a month ago for a users group in Dallas, so I wasn’t completely unfamiliar with the material. I was a little rushed for time due to the late start, but overall that presentation went rather well.

After a lunch break, Ian Thain of Sybase presented - Model-driven SOA. His presentation included some interesting demonstrations of model-driven SOA using Sybase tools. Next was another Expo Floor break and snacks, followed by the SOA Power Panel.

I had the pleasure of participating on the SOA Power Panel along with Miko Matsumura (Software AG / webMethods), Kevin Hakman (TIBCO), and Sandy Zylka (NextAxiom). Jeremy Geelan moderated and we had some great discussion around SOA, convergence with other trends, economic impacts, and more. The panel session was recorded and I will post a link to it once it is made available.

I don’t know what happened for the rest of the day as I was occupied by various discussions in the late afternoon and then in a bit of sight-seeing in the evening (Coit Tower, Treasure Island, Lombard Street, and more).

San Francisco SOA World power panel governance adoption design patterns strategy selective soa soa training soa mentoring Web Age Solutions

Posted in Conference, SOA | No Comments »

About Me

Kyle Gabhart

♦ IT Evangelist & Strategist

♦ Popular Public Speaker & Author

♦ Director of Emerging Technologies for Web Age Solutions

Kyle's SOA Book

Search Posts

About Me

Kyle's SOA Book

Search Posts

Tags

Recent Posts

quark xpress 6.0 demo,

freeway 4 pro for mac

Buy cheap software Rhino 4 oem

acrobat reader 6.0,

Buy cheap software Rhino 4 oem

acrobat reader 6.0,

acrobat reader 6.0,

Rosetta Stone Version 3: Italian Level 1, 2 & 3 Set for mac

adobe acrobat professional 8.0

Rosetta Stone Version 3: Italian Level 1, 2 & 3 Set for mac

acrobat reader 6.0,

quark xpress 6.0 demo,

acrobat reader 6.0,

freeway 4 pro for mac

acrobat oem software

acrobat reader 6.0,

Sonic.RecordNOW.Deluxe;

acrobat reader 6.0,

Sonic.RecordNOW.Deluxe;

Pinnacle Studio plus 10 multilanguage,

downloadable oem software