Owning Hardware is soooooo 2008

February 6th, 2009 by Kyle Gabhart

As the fallout from the economy takes it’s toll: staff layoffs, reduced capital expenditures, dwindling revenue, etc., enterprises of all sizes are looking for opportunities to trim back on their fixed costs and move toward business models that are more agile, scaling up AND down with demand. Call it Cloud Computing, call it Service Oriented Architecture (SOA), call it service orientation, or just call it good business.

A couple of days ago, Fortune magazine observed this trend in their Tech Daily post: “Goodbye hardware. Hello, services”

The core of the article can be found in a quotation and subsequent summary statement from the article’s author:

“As Salesforce CEO Marc Benioff said back in November: In this economy, ‘customers are not going to bring out their checkbooks for the cost and risk and complexity of big database purchases, or application server purchases, or data center purchases.’ They’re buying more services, and fewer servers.“

The article sites such data points as declining earnings for PC and server manufacturers, strong growth in the services and SaaS arena, and a huge jump in IT outsourcing initiatives (a key business driver for Cloud Computing, as I described previously: Real Value in the Clouds).

That’s two Fortune articles this week on Cloud. Good work mainstream media!

Posted in Cloud, SOA | No Comments »

SOA and The Year of the Ox

January 27th, 2009 by Kyle Gabhart

Communities the world round celebrated Chinese New Year yesterday. 2009 is the year of the Ox, and with it comes new insight and possibilities into what the year holds for our world. According to Chinese tradition, the year of the Ox represents “prosperity through fortitude”. The Ox symbolizes that success will come to those that buckle down, dig in, and persevere through hardships. In contrast, 2008 was the year of the Rat. The Rat symbolizes pioneering, cunning, ambition, and even a sense of entitlement. There is a time and a place for everything, and the time for the rat and the need for the ox has certainly come. Given the economic climate and the state of companies, governments, and organizations of all shapes and sizes, this is an apt and timely metaphor.

2008 was an exciting time for exploration and pioneering possibilities. SOA adoption was in full swing, the virtualization discussion morphed into Cloud computing and took a prominent degree of mindshare in the process, and the Web 2.0 momentum transformed into an emphasis around enterprise mashups. 2009 presents a very different reality. The time for pioneering and cunning must give way to the much more pragmatic and focused intensity symbolized by the ox. It is time to buckle down, dig in, and solve real-world problems with SOA and its related initiatives.

Ox-inspired Tips for Success with SOA in 2009

If you don’t have a real business case, you have NO business pursuing SOA. Moreover, the business case should lead you to select SOA rather than selecting a business case to justify your decision to adopt SOA.
Invest in SOA selectively this year. Education and re-skilling will yield results almost immediately. Governance investments will also bear fruit fairly quickly. Investments in tools and infrastructure should be closely scrutinzed. Over-hauling your high priority, mission-critical systems might be too risky (and expensive) at this point. Developing an Enterprise Architecture (EA) framework and moving your enterprise to a canoncial data model might be best to put on the back burner for now.
Cloud computing offers some really compelling possibilities, but the increased buzz around Cloud is hardly enough to warrant special attention. There have been no revolutionary standards, tools, or platforms made available that have recently changed the game. If you weren’t looking into virtualization, grid, or SOA before this year, it probably doesn’t make a lot of sense to launch out into Cloud right now.
Develop fewer services that each provide clear and measurable value to the enterprise rather than developing a broad array of services in hopes of providing a catalyst for progress and innovation.
Architectural layers and governance oversight must be value-added. There are no bonus points for adding a service layer or additional governance requirement in the absence of a tangible value (this holds true for all project aspects, but architecture and governance are common culprits for excess).
Develop services that meet their service interfaces. Nothing more, nothing less. This is always good advice, but the Ox reminds us how critical it is to avoid scope creep in the form of gold plating.

Opportunities exist for service orientation and the array of related initiatives (SOA, SaaS, Cloud, Mashups, etc.) in 2009. The key is to ensure that real business value is driving your initial and continued adoption efforts, that you invest in education, and continue to prioritize governance to keep everyone focused on the goal.

The current economic climate and corresponding budgetary pressures are a sober reminder that the extravagence and excess over the past couple of years cannot continue indefinitely. As companies announce layoffs and organizations around the globe rein in spending, it can be discouraging. There is, however, a silver lining. The Ox does not symbolize survival through fortitude, but rather prosperity through fortitude. Invest cautiously, move forward with service orientation pragmatically, and you can certainly come out ahead in 2009.

The future is bright.

Be the change.

SOA SOA Expert Cloud Computing Web 2.0 SOA adoption SOA success Service Orientation SOA Methodology SOA training

Posted in General, 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 »

Live from Times Square

August 19th, 2008 by Kyle Gabhart

Well, I have officially had my 15 minutes of fame. Back in June, I was invited to participate in a SOA Power Panel for SYS-CON in New York. I’ve participated in a number of expert panels over the years, but this one was unique. The discussion took place in the Reuter’s TV studio in Times Square. The room had a professional camera crew, a sound stage, CNN-style set, and the windows behind the panel overlook Times Square (you can actually see some of the digital billboards in the background). It was a fantastic experience and we had a really great discussion around the current state of Service Orientation and the future holds for enterprises both large and small with respect to technology innovation and successful SOA adoption.

You can find the videocast here: SOA Power Panel - Live from Times Square. There is a brief commercial and then it takes you right into the panel discussion.

I had a ton of fun participating in it and hopefully you’ll find value in viewing it.

Posted in Conference, General, SOA | 1 Comment »

The Jungle Book

July 28th, 2008 by Kyle Gabhart

I’ve just published a SOA book through Wiley Press and it is now available on Amazon (hence the catchy title for this post). Woo-hoo!

The book was a ton of hardwork, but I am quite pleased with the result. The aim was to address what I considered to be a significant gap in the marketplace — a pragamatic book on SOA that is more business oriented and less technology focused. So I signed up Bibhas Bhattacharya as my co-author and set out to write such a book. There are vast amounts of resources available for techies that are interested in SOA. There are even a fair number of resources available for managers. If, however, you are a business leader, executive, or are actively trying to get the buy-in of one, where do you turn? What resource is there to help you grapple with important questions like:

What is SOA really about from a business standpoint?
When is SOA applicable and when is it not?
How should an organization go about adopting service orientation?

There are a couple of excerpts available for you to preview the content:

Excerpt of Chapter 1 “SOA Primer”
Excerpt of Chapter 3 “SOA Value Proposition”

When you get the opportunity to read through some or all of the book, I would really appreciate your feedback on the content. I hope that many will find it to be a useful resource to facilitate pragmatic SOA adoption.

SOA Expert Kyle Gabhart SOA Book SOA Adoption Pragmatic SOA Executive Summary SOA for Executives SOA for Managers SOA for Business

Posted in SOA | No Comments »

Service Design - Composite Schema

July 22nd, 2008 by Kyle Gabhart

The structure of data for your service operations is very important. This is the primary way that information is transmitted within a service oriented environment. Moreover, the data model that you use for services will largely dictate service compatibility, interface flexibility, and to some degree will determine the extent of interoperability challenges that you will have as your service catalog expands.

One effective technique for defining the schema for services that I have seen is something I describe as a composite schema. There is a rather large assumption that many service designers make, which is that the schema definition for a service must be atomic. That is to say that you either define the entire schema inside the service interface file, or define the entire schema in a separate file. This is fine for the first few services, but what happens if you are six or nine months into service orienting your enterprise and a key aspect of your data model changes (perhaps the ‘customer’ element or ‘product’ element)? You’ll have to go and update the schema for each and every service that uses these elements. The alternative, is to wrestle with each service design team and get them to agree to a single schema that everyone uses (which becomes bulky and unwieldy). The answer to all of this, is a composite schema.

A composite schema is one that draws its definition from more than one schema file. Thus a service interface has some of its data elements defined within one schema and some defined within another (some choose to have a single schema per service interface and simply have that single schema file reference several other schema definition files). This allows service definitions to be reused and common elements to be defined only once. When changes inevitably need to be made, this keeps the maintenance overhead to a minimum.

So what should the design of this composite schema look like? There are several possibilities, but a common approach is as follows:

Core Data — This schema defines common elements that are consistent across the board within your enterprise.
Division / Line of Business Data — The next layer tends to focus upon some major segmentation such as industry or business division, etc.
Product or Service Line – Data structures that are common across a product line or service category are defined in this schema.
Service Data — Unique elements that are specific to the service are defined here.

Obviously, you could define as many or as few categories of schema as you like. The goal here would be to minimize how much of a service’s data elements are defined as service-specific data types. The ideal, would be for 80% or more of the data used within your service interfaces to draw from common, reusable schemas.

Composite schema are by no means revolutionary. This is a capability that has existed for years. The problem, of course, is that there is a tendency to craft solutions in a traditional, silo-oriented fashion. Service orientation drives us to think more about exposing and consuming services across business units, in the broadest possibly context. It also drives us to compose solutions from existing assets before creating new assets. All of this leads to a need to work smarter, not harder, and look for opportunities to reduce maintenance costs and more effectively utilize resources. Composite schemas represent one such technique.

Posted in SOA | 2 Comments »

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 »

Service Oriented Dinosaurs

June 2nd, 2008 by Kyle Gabhart

Primitive man and woman were forced to adapt to their environment to survive. Animal hides for clothes, crude weapons and tools made out of stone or bone, and roots or berries for food (perhaps sabertooth steak or terradactyl ribs if company is coming over). Eventually, some nearby tribe discovers fire, but reports of fire-related injuries and property destruction lead our cave dwellers to avoid this new magic. These primitive humans are doing fine with their current capabilities and they are able to meet their basic needs without dabbling with such things. Over time the nearby tribe’s use of fire expands and one very enterprising woman invents pit fired pottery. The more primitive people have heard and seen the potential of this new breakthrough and are interested in using it. Alas, the obstacles to adopting this innovation are not trivial. They must learn how to create fire, handle fire cautiously, locate and stockpile flint and tender, develop fireproof tools, create fire pits, learn to craft with clay and finally develop a process to fire the clay pots successfully. Lack of education, skills, infrastructure, resources, and processes hinder their ability to progress. Perhaps the greatest barrier for these primitive people is fear of the unknown and risk of failure. Thousands of years later, we are faced with the same technology adoption challenges — education, skills, infrastructure, resources, processes, and fear.

Modernizing legacy information systems is not unlike the modernization efforts that have occurred for thousands of years. In fact, legacy or heritage systems are often referred to as ‘dinosaurs’. Correspondingly, the same types of obstacles must be overcome:

Education — There is a mindset shift that must take place to understand the service oriented way of thinking. At first glance, services are just fancy objects. The reality is that service orientation requires a much broader, end-to-end view of the enterprise, complete with process-centric alignment, layered architecture, contracted interfaces, standards-based connectivity, and full life cycle governance. I have blogged about the alignment of service orientation and the unique qualities of SOA before. Also, David Ing has some interesting thoughts on service orientation.
Skills — A well documented skills gap exists around service orientation. Joe McKendrick sites it as one of the two things killing SOA in 2008 and the guys over at ZapThink have been alerting the industry to the dangerous SOA skills gap for quite some time. Why is this? Service orientation skills cannot be acquired by attending a conference or reading a book (although I do have a book that I HIGHLY recommend). Academic learning as well as hands-on mentoring is required. Moreover, there are nuances to effective service orientation, service design, process alignment, and enterprise governance that require time and experience to develop. There are new technologies, design patterns, techniques, and methodologies that must be introduced and ultimately absorbed. This will require instructor-led training, research, hands-on mentoring, and practical experience to develop proficiency in these areas.
Infrastructure — Contrary to popular belief, a service oriented infrastructure cannot be achieved by purchasing an Enterprise Service Bus (ESB) from a vendor and adding water. There are, in fact, a variety of infrastructure elements (service registry/repository, governance suite, business process engine, policy manager, policy enforcer, and etc.). There is a great little SOA infrastructure white paper that a consortium of vendors put together a while back. Additionally, be sure to avoid the trap of assuming that you need to have your SOA infrastructure fully mature on day one. Eric Newcomer has a great post from a couple years back regarding an incremental adoption of SOA infrastructure.
Resources – There are several ways to slice the resource issue. For effective adoption of SOA, you will need a pool of human resources (with appropriate education and skills), technical resources (infrastructure, knowledge management and collaboration tools, as well as design and development tools), and you will need expert resources (developed in-house, or brought in from an outside source initially).
Processes — All the education, skills, infrastructure, and resources in the world won’t amount to a hill of Java beans without effective processes for governing the adoption of service orientation. You will need processes for service selection, service design, quality assurance and testing, policy enforcement, and runtime service management. Effective governance can make or break your adoption of SOA. I have blogged on the importance of service oriented governance numerous times.
Fear – People fear change. Service orientation appears threatening to many people at first due to the changes required in adopting it. New patterns of thinking are required around how to solve customer problems. Skills must be adapted, other skills developed from scratch. New infrastructure and resource pools must be created and processes must be adapted and new processes created. These changes can be intimidating. A considerable degree of people change management must be accepted as a part of a successful transition toward service orientation.

Service orientation adoption is challenging in its own right. It becomes increasingly challenging when you factor in the dinosaurs that must be modernized as a part of the adoption process. Immediately, questions begin to arise:

What systems and/or business processes should be modernized?
Should we migrate, expose, or leverage our existing legacy assets?
Should adoption occur within a particular line of business or across the whole of the enterprise?
How will modernization impact existing teams and project roles?

These questions and many more must be explored as part of the adoption of service orientation. I explored several of these topics in a recent public webinar - Enterprise Modernization and SOA Concepts (pdf).

Another resource you might consider is a new course that Web Age has been offering since April of this year. It is a two-day workshop that explores the modernization of legacy applications, SOA concepts, modernization challenges and risks, and various strategies for modernizing legacy systems. It is aimed at team leads, architects, managers, and legacy application support personnel. For more details, check out the course details - WA1657 Application Modernization and SOA Concepts.

Adopting service orientation and “moving out of the Stone Age” is not a simple task. It requires intentional allocation of time, energy, and resources. It cannot and should not be approached in an ad-hoc fashion. Technology adoption has always been challenging, just like when ancient man and woman adopted fire. When it comes to service orientation, be sure that you work through the necessary steps of adopting education, skills, infrastructure, resources, processes, and addressing the fear factor. Otherwise, you just might get burned.

Adoption education ESB Governance Legacy Modernization selective soa SOA Strategy Tools

Posted in SOA | 1 Comment »

Only a Fool Would Build Reusable Services

April 25th, 2008 by Kyle Gabhart

For those of you out there championing the cause of service orientation, the title of this post may catch you off guard. Likewise, casual observers of the service orientation movement might assume that developing services for reuse is the norm. Believe it or not, my title is not ironic, sensationalized, or tongue-and-cheek. I honestly believe that given the way most enterprises have established SOA, only a fool would build reusable services. Why might you ask? Simple. Rational self-interest.

What does rational decision-making have to do with adopting service orientation and developing services for reuse by others? I’m glad you asked. The simple fact is that the creation of services as reusable rather than one-off solutions is not free. Experts peg the expense of creating reusable solutions anywhere from base cost +30% to base cost +200%. It is significantly more expensive to build for reuse. On the flip side, it is considerable less expensive to reuse an existing service. Experts peg the expense of reusing a solution rather than creating one from scratch to be anywhere from base cost - 80% to base cost - 20%. In short, developing reusable services is very expensive, but once you have reused a service multiple times, a return on your initial investment will emerge. I blogged about this several months ago (SOA ROI, deconstructed) and provided a link to a whitepaper that explores this subject in more detail.

From an enterprise perspective this all seems very logical and the additional investment is easily offset by the value of the reuse over the long term. The problem is that in the short term, rational self-interest will drive individuals to never develop reusable services.

Consider the following scenario:

Bill is a project leader and is creating a service oriented product portal. He realizes that several of the services he needs could be designed in a fashion to foster reuse. As a good citizen of the enterprise, he directs the team to design these services in a more flexible and enterprise-centric fashion. Additional effort is spent during design and potential enterprise customers are interviewed regarding their potential needs. The added cost puts a strain on his budget but is certainly the best answer for the enterprise overall.

Sharon is another project leader in the same division as Bill. She is creating a product reporting application. She discovers that several of her requirements can be met by simply reusing the services created by Bill’s team. Other services that she needs are then developed as unique, one-off services to contain costs. Sharon uses a fraction of her budget to produce this solution, freeing up resources to meet other goals for the year.

At the end of the year, both Bill and Sharon will be judged based upon what they were able to accomplish with their respective budgets. In the absence of some acknowledgment of Bill’s contribution to the pool of available services or similar affirmation of Bill’s decision, then he is in hot water. Sharon looks like a hero and Bill comes off as a fool. Knowing this, Bill will be less likely to develop reusable services in the future (unless he can directly benefit in a very short timeframe).

Adopting service orientation and encouraging reuse is great, but what will compel divisions and individual project teams to actually play ball? In the absence of some sort of incentive structure, charge-back mechanism for using services, or similar recognition for contributions to the greater good, no one will develop reusable services. Rational self-interest will drive each group and each team to develop services that only help themselves and which will, in effect, re-create the same silos that we are trying to supplant.

All of this points to a very real gap that exists within many enterprises that are adopting or at least exploring SOA – lack of business buy-in. Someone within the business needs to recognize the true cost of SOA and put in place some sort of incentive structure to encourage teams to contribute to the greater good of the enterprise. SOA is not a short-term, quick-win approach. It requires strategic planning and long-term investment windows.

So what if you have no business buy-in? Are you sunk? No. You may not be able to get traction around reuse, but you can go for ease of integration, the benefits of standardization vs proprietary solutions, lower maintenance costs due to the loose-coupling that SOA offers, the configurable nature of services and process, and other benefits that do not depend upon long-term reuse time windows.

Adopting service orientation requires a considerable amount of strategic planning and up-front design work. There are a variety of business drivers around SOA and reuse is certainly a popular one. Is it foolish to develop reusable services? It is if you attempt to do so within an organization that is not viewing things strategically or is unaware of the long-term impacts of service orientation. In the absence of business buy-in and strategic incentives, only a fool would build reusable services.

Service reuse SOA reuse SOA adoption SOA expert SOA mentor resuable services SOA value SOA ROI ROI calculation

Posted in SOA | 1 Comment »

« Previous Entries

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