One of the toughtest aspects of the SOA industry is trying to keep track of all the acronyms. It seems like the IT Industry’s Acronym-izer is running at full capacity. Well, a few days ago I came across this article on InfoQ that helps you Make Sense of All These Crazy Web Services Standards. It’s a great article that describes all the standards within the Web Services arena as well as goes into a concise description of each of them. I’ve been looking for a list just like this for way too long…so a big thank you to Michele Leroux Bustamante for creating this article!
-
30May
Tags: SOA, Standards, Web Services
-
25May
[ I've been a bit distracted over the past few weeks and haven't been able to post much. Who knew that just coordinating to put a new roof on your house could be so time consuming (that doesn't make me look forward to the actual 'put on' process). ]
It’s a common notion that things happen in threes. So when I see the same theme three times in a short period I see that as the universe telling me something. Recently, it was telling me about how to make SOA happen.
First, William Henry, a colleague of mine at IONA, found an interesting article that talks about How Sun Sells Its SOA Dog Food To Its Own Employees. While that article is a bit confusing with regards to it’s spin on Sun’s SOA solution (hard to tell if it’s author is positive or negative about Suns JCAPS) the real intent is to talk about how to present SOA to the end user. The article quotes a Senior Manager for Integration Services at Sun regarding how he talks to his internal customers about using the Sun SOA solution to enable re-use within Sun’s IT infrastructure and remove stove pipe applications. The key take away from this article is that even within a large IT Vendor, the people that own IT systems can’t always see the value of SOA. And when they do see the values (i.e., reuse, lower costs, agility) it’s hard for them to want to do SOA.
Second, another IONA colleague and I were talking about funding models for SOA. There are a number of customers that we are working with right now who are in the early stages of a SOA deployment or reaching the first release of a SOA infrastructure. Each of these customers tend to use a hybrid funding approach for SOA. A combination of ‘corporate money’ given to a centralized IT organization to jump start a SOA initiative as well as ‘project money’ or ‘LOB money’ that is used to fund the growth, maintenance, and ongoing support of the SOA initiative by the centralized IT organization. However, even with a funding model in place, a common theme across all these customers is that you need to have a top down driver for SOA within an enterprise to really gain enterprise wide adoption and receive enterprise wide value from any SOA initiative.
Third, today I read a great writeup on the Momentum SI Service Oriented Architecture blog about Talking to the Business about SOA. Jeff from Momentum SI provides a good overview of the fact that when talking to businesses about SOA, you need to talk to your current audience. Any SOA initiative at an enterprise level will cross multiple business areas within the company. Jeff does a good job of describing the differences of key business areas and how you need to keep these differences in mind when talking to them about SOA. I do see one interesting theme underlying all of the business areas discussed…a corporate drive for SOA.
To me, all three of these items point to a single fact: that there needs to be a corporate level driver for SOA in order to truly see the long term value and benefits of a SOA initiative. That doesn’t mean that SOA initiatives can’t be done in small incremental bites, but those bites will only happen if the mid-level person driving them has the political clout over peers to make them happen. Without a high level executive (or corporate) initiative saying “Thou Shall Be”, these small SOA bites will never grow into enterprise returns. The internal politics will eventually stop them dead in their tracks.
Tags: IT Funding, SOA, Sponsorship
-
10May
(Disclaimer: I currently work for IONA Technologies)
You hear a lot about departmental adoption of SOA and how most SOA deployments are not happening at the enterprise level (see SDTimes article about Will SOA Become The New Siloed App?). While this has been the historical status of SOA—and one of the smartest ways to migrate to SOA in a cost effective manner—there are some enterprises who are forging ahead with SOA, enterprise wide.
For the past two months, I have been working with a large financial institution on an enterprise SOA project. The goal of the project is to increase re-use within the enterprise which will help rein in the IT spend on duplicate application development and migrate code off of legacy systems through the construction of a new services based platform for the enterprise. What do I mean by large? Phase 1 has over 200 external facing services (akin to legacy “applications”) within the project and each service is composed of multiple internal services.
IONA was brought in during the middle of a development cycle to help identify and address various risk areas that were being bantered around by the various development teams. This was accomplished through the use of our Value Assessment Program that I talked about earlier.
One of the interesting things that we found was that there was a problem of trying to do integration testing of all these services. The issue was less about the services themselves and more about the Interface Agreements that governed how a service was used. Since the project was leveraging services based development that had happened in the past as well as service-enabling vendor provided applications, the aspect of service interfaces was a lot muddier than the ideal SOA implementation talked about in books.
The service providers were not creating a services and saying “here’s how you access it”. There was very complex business functionality and message passing that already existed and needed to be migrated to this new platform (which in its own right is an topic for a few discussions). So both the service provider and service consumer were working together to define the interface to a service. And then business happens: new regulations come about, improvements are thought of, changes need to be made. But there was no process or governance behind those interface changes. One side would make a change without consulting the other side. The net effect: a massive service based platform that wouldn’t work the first time it was plugged together and turned on in QA.
This is where the fun starts: internal discussions and finger pointing at where the problem originates. Since there was no process for defining and governing the interface agreements, the environment was ripe for momentum freezing politics which leads to slippages in delivery schedules.
With everything being tracked and reported on within this framework, the status of service development team’s development is visible to everyone in the organization. When politically induced tensions start to drag on the project, transparency can be one of the best solutions.
Tags: , Interface Agreements, SOA
-
26Apr
(Disclaimer: I currently work for IONA Technologies)
My other alter-ego is back, Greg the Architect has a new episode out that talks about SOA ROI. First, we should all be afraid when there are too many acronyms used right next to each other…
Even though I have issue with the transparency of the sponsorship behind Greg, I have to admit that the episodes are very well done, highly relevant (as anyone who has been selling or buying enterprise technology, specifically SOA technology, can tell you), and funny.Side Box: I do have to congratulate the TIBCO Marketing team. I was contacted by their Worldwide Direct of Marketing and was informed that they received an Internet Advertising Competition (IAC) Award by the Web Marketing Association for the first episode of Greg the Architect. Dan and Ram, keep up the great work!
This episode talks about something that is near and dear to my heart, how to measure the value of technology. This is one of the corner stones of my new role at IONA. As part of the Customer Value Sales Team, I’m responsible for working with IONA’s west coast account teams to apply IONA’s value selling model, what we call the Value Assessment Program, to how our clients use IONA’s technology within their enterprises.
Everyone has heard the terms ROI and Value before. If you’re a buyer of technology you have heard countless vendors claim ROI numbers for their products or provide statements of value that you can achieve through the use of their products and/or solutions. If you are (or have been) a vendor selling technology then you have most likely been given ROI and value statements from your marketing department at some point to assist with your sales. You might have even used one of those magic ROI Calculator spreadsheets to help show a customer the value in hard numbers (more on that later).
I think this is a good topic to cause us to sit backwards on our horses to see where we have traveled over the past few years in technology with regards to RIO and Value.
A long, long time ago, back when you needed to go through 2+ years of serious and all encompassing training to receive the title of sales executive, value was something that described how a technology would directly impact your business. Granted, when dealing with new technologies there was a bit of faith involved in accepting the numbers. But that risk is what lead to great rewards. During the most recent bubble years, when a monkey wearing a vendor’s logo polo shirt could sell technology, the concept of understanding (or explaining) the business value that a technology purchase would create was considered “old fashioned”. How many millions of dollars were wasted…
The past five years has seen the industry pendulum swing back. Right after the bubble burst, technology companies started to realize this “new way” of selling technology, based on a calculated Return On Investment. Unfortunately, a lot of these ROI models were just smoke and mirrors reflecting MBA speak around a product. I have seen countless ROI calculators that would generate a positive ROI…even when all zeros were entered int them.
Now we are back full circle to businesses expecting to see financial validation behind their technology purchases. Most monkeys are back in the zoo (though I think we are running short on animal catchers), and an account executive for enterprise technology and solution companies are expected to be business partners of their customers. This means helping their customer use the technology to help address business problems their customers are facing or sometimes ones they don’t even see. This also includes explaining that business value in the customer’s business terms.
This was one of the primary reasons why I decided to join IONA almost a year ago. We have a dedicated team with executive support focused on helping us and our clients understand the value that can be achieved through the use of IONA’s Distributed SOA Infrastructure technology. Our Value Assessment Program (VAP) involves a commitment from both IONA and our clients to understand this value. This 30-45 day program consists leveraging IONA’s decade long set of experiences from Global 2000 companies to conduct focused interviews within a client’s organization, validate of the risk areas identified, and jointly craft a solutions to minimize these risk areas. This solution’s core is a value statement, built upon numbers provided and confirmed by the client’s people, detailing how this solution will impact the client’s business.
As I promised in my entry about recent changes back in February, I was planning on writing more about this Value Selling Methodology. I have not had a lot of entries on this topic since due to the success that we have been having with it in the field. I have been working clients over the past three months detailing how IONA can savee them millions of dollars in technology spend or create millions of dollars of business revenue thought the acceleration of their software development lifecycles.
Consider this my renewed pledge to start sharing more of this with you in the near future. To quote a good friend of mine “a couple of no-doze and a pot of coffee and I’ll be up all night writing manifestos.”
Pour me another cup!
-
26Mar
Everyone has an alter ego out there in the world. I found out today that I’m lucky enough to have two. My first is my twin out of Rhode Island that is a musician and owns the domain of our names. (I’m still trying to figure out if we are related in the family tree or not…). The second I discovered this morning…Greg the Architect.
Tibco, don’t hide the fact that your doing both of these…it usually burns the audience you’re trying to capture. At the same time, don’t swing the other way and make these both Tibco items. There is a middle ground in there that has to be found…I think there close, but think they need to be a bit more up front with their involvement.
Either way, I found it funny and worth sharing.