Web Services is a new model, essentially object-oriented programming for web-based objects. The April 2000 SOAP 1.1 specification was a step in this direction in that it described how to use XML formatted messages for requests and responses. UDDI is the piece of the puzzle that will enable businesses to find these services. Web Services Description Language (WSDL) is the XML vocabulary that will describe services and service providers. Therefore […]: Web Services = SOAP + UDDI + WSDL
A decade later we are still pondering about the meaning of Service or Web-based objects without even considering how foundational SOA has been to Information System Construction.
InfoQ has gathered a virtual panel of Enterprise Architects who have lived and implemented SOA for most of this decade to better understand what SOA means to IT in 2009.
Our participants include Jeff Andres, Eric Ballou from MomentumSI, Dave Hollander from Saber and William El Kaim from Carlson Wagonlit Travel.
InfoQ: We have spent 10 years doing SOA. What are your thoughts? How will SOA look like in the coming decade?
Eric: Wow, I can’t believe we’ve already hit 10 years, but here it is. Generally, I am amazed that so many companies have thought that just doing web services was SOA after so much effort by vendors and gurus to educate people. Companies who haven’t started on the SOA path will continue to struggle growing their maturity without some strong ground breaking efforts by both their business and IS teams – they face a very strong technology entry to market against their competitors who have already gone down the SOA road and learned their internal lessons. Fortunately, as Gartner points out, SOA is entering the “Slope of Enlightenment”.
The future of SOA is that it will start to fall under the label of new methodologies and practices as vendors shift to more business/user centric services and products. Labels like Web 3.0, business driven architecture, and user centricity where empowerment of the end-user is a great subtle shift in this direction - or as Yahoo puts it – it’s about Y!ou. Information Services has to put a lot in place (read services architecture) to help the empowerment get into place and SOA/BPM/cloud is a small step in that direction.
Jeff: In looking at SOA, it is very similar in nature to functional design and constructs that were done in the 80’s. In reviewing what has transpired since then to now, and then forecasting to the future would identify additional maturity in areas of “event” driven architecture, process based architecture, as well as making SOA lighter weight – as the new types of languages, media and devices will call for this. So why or how did I arrive at these areas? Step back for a moment and understand where is SOA today and where and in what areas could it go? Presently SOA, from my vantage point is not hitting in the real-time and event driven space, thus languages and constructs of “event driven” (interrupts, forks, joins) and the like need to be accounted for. A debate may open up whether this is language based or this is architecture. I’ll leave that alone. Next, SOA has definitely made a presence and many big vendors have scored (like SAP). However, what they have missed on is the delivery of “process”. Thus, the marriage and joining of process and service will need to come together better in the ensuring years. Lastly, technology is always changing. Years ago devices like iPhones, iPods, Smartphones, BookReaders, did not exist. If we are to build and deliver functionality in these footprints, SOA will need to also become SOA-lite! Akin to how Agile changed the development practice of Waterfall or OOP, SOA will need to morph to the new technologies on the horizon.
William: SOA will really focus on Data and Business process as a service. In the coming years, SaaS suppliers will focus on automated and configurable business processes that will drive to the on demand world and the business value chains of the company. SOA will also be used to enable flexible and sustainable IT services like security (Authentication, federation, Identity), logging, Monitoring, analytics, etc. The portal will become the entry point for the service oriented company.
Dave: One adjective comes to mind when it comes to the future of SOA: submerged. SOA will become as ubiquitous as client-server once was. New architectural approaches will get the limelight, but most likely they will all build upon SOA principles.
InfoQ: SOA Governance became a major component of SOA right around 2004, do you think it has helped or hindered SOA?
Jeff: It definitely has helped! Although one needs to identify that there are two sides of every coin. First, governance (depending on its strength) has provided some level of control and structure to the creation and management of services and lifecycle management. Without it chaos would wreak everywhere and then we would just have a plethora of small “unused” (aka, non reused) services. It also have given a notion to developers, management and others that oversight is important. On the flipside of the coin, it also suggests that innovation may get stifled due to bureaucracy. Again, this is all dependent on the level of governance and what it means to an organization. I believe the split is 65/35 in favor of governance to the positive.
William: SOA management hindered SOA of course. Governance is not something you can solve by installing a tool or creating a bunch of web service. You need to manage organization change, train people, make people mentality evolve. Depending on the company Business and technical skills and maturity level, the gap can vary greatly. We can however remarks that open source tools for SOA governance have also evolved greatly from a pure repository/registry standpoint, to a more workflow oriented platform ... Governance will be more and more important in the future, since the need for controlling services usage, billing, access and integration will be more and more important.
Eric: As companies tried to execute the SOA vision, they quickly learned that an ounce of prevention is better than a pound of cure. Governance is just how we ensure mature work happens. The learning curve of SOA Governance is finally getting over the hurdle of people saying, ‘Oh, I haven’t done that yet and neither has the guru we reference.’ As any change, modification of the corporate governance and software development lifecycles to support SOA hasn’t been all that easy – even with the help of very seasoned SOA specialists to walk companies through the process safely. This organization learning curve for companies less adaptable to change has hurt the SOA effort, but those who persist find its worth the effort. Overall, SOA Governance properly applied has helped SOA as it has enabled visibility to the business and traceable ROI for project efforts. So many of the architects I’ve worked with have been empowered by governance to really get close to the business and make the life of the development teams so much easier.
Dave: SOA Governance has definitely helped SOA. Good governance is not SOA governance but rather the embedding of SOA governance into existing and perhaps enhanced governance processes.
InfoQ: Service Governance has often been touted as a way to gain better business / IT alignment. How do you perceive the business involvement in Service Governance?
Jeff: Having just passed my ITIL exam I would exercise a sense of “caution” to the notion and support of service, as it is going to be overused and exploited to much from an IT perspective. However, with respect to SOA Service Governance, I believe that it affords the opportunity for both the business and IT “join as one” in developing components that are of value for each other. In no other case (okay, maybe in business process) has IT and the business gotten together whereas they both benefit. Typically, IT meets with the business to just understand the requirements and then they run off to their labs and develop the solution. In Service Governance, they actually have the opportunity to discuss in an open forum from which both walk away winners. The business gets to understand a little what goes on within IT and IT wins by having both business backing and support of what they are doing.
William: The business is not interested in service governance, except if you can prove that it can bring revenue to the company or can accelerate the time to market? As of today, alignment does not exist. The quick evolution of the business and its needs make impossible IT to align with it currently. The current IT process and technologies are not mature enough. That's why we need to change the IT paradigms in place. Specifications made by the business should be reused in their form to create software. That's the model driven approach. New languages and Platform are also enabling this acceleration. The only variable that we cannot accelerate enough is the human being.
Eric: As I mentioned in the previous question, SOA governance work has really empowered architects to get close to the business. This closeness has fostered a better sense of control in the decision making process for business owners and a greater ability by the architects to deliver what is needed. Governance succeeds by bringing the two together in quick ‘natural’ steps of company operation as new ideas and needs are created by the business or the architect on their behalf and then validated/approved as delivery ensues. While this sounds so simple and ‘easy,’ getting to that communication and process level requires a lot of self-evaluation and critical guidance for companies. I’m not seeing a lot of maturity to provide that guidance in the market to navigate those roads yet, so business owners are still being frustrated by what they perceive should be an internal IS matter.
Dave: This involvement is critical, otherwise, services and SOA will remain cost savings and efficiency initiatives. Of course, Service and SOA may well not be explicitly named when we interact with the business, but they must drive the way systems deliver value.
InfoQ: There is a lot of debate about “reuse” in our industry. Do you see reuse being successful in our industry?
Jeff: The “Holy Grail” is reuse. How can I build and make items more effective and efficient. When technologists are able to deliver on this through means of SOA the value is huge! However, reuse is typically not seen right away and takes years of deployments to start seeing the results. Further, it takes good “architects” and “engineers” in order for this to happen. All too often top level management expect results in less than 18 months and unfortunately results don’t typically manifest themselves that fast. Service Governance can assist, but it takes good leadership and buy-in from the organization (culture) to really “adopt” SOA. As mentioned previously, if SOA and reuse are only given lip service, then they are bound to fail. No matter of governance will assist as it will not be viewed in the “positive” or value offering capability.
William: The best example of the difficulty to talk about reuse is the portlet. In Portals, we need to build portlets. But most of the portlets will be used once, in the first page of the portal. Here, no reuse is made, but portlets are necessary for portability. I will say, that reuse is now less and less important. What is important is to create sustainable asset in the company. Those assets are the IP of the company and are possess an intrinsic value.
Eric: You’d need to qualify which ‘reuse’ debate as there are several. As a whole – every company is concerned about leveraging their resources in the most efficient manner possible. However, lack of visibility by both business and IS into what they own as IT assets has severely prohibited companies in maximizing that benefit making reuse a marginal success story. Service Governance has accentuated the need for visibility and created a requirement to know what IT assets are in use, who’s using them, who might be interested in using them, and any gaps there are in their future use. There have been a lot of styles and use of technology in trying to answer the visibility question, but the success stories have a HUGE increase of not just reuse but the capability to map metrics of assets back to the business in understandable, measureable ways.
Dave: I am not sure. We avoid reuse as a primary selling point since it is too hard to measure and quantify.
InfoQ: Could you describe some of the elements of successful SOA or Service Governance organizations?
Jeff: Great sponsorship and endorsement from top leaders who embrace this change. Staff members who are willing to take a chance and enter this arena and be change agents! Modification of the development process, akin to developing OO versus waterfall: upfront work on service design is paramount to scoping and framing services that are both meaningful and will have a chance of reuse in the future. A governance model that “matures” over time; set an understanding level that it will mature and change and then execute on it. Do not be to overbearing at the outset, otherwise you will not have any followers.
William: We need:
- A clear service taxonomy of services exist and is implemented in a registry to provide an always accurate service catalogue.
- Any service configuration is done through metadata stored in a specific repository.
- The full service lifecycle is managed (design time, run time, end of life) and releases are managed.
- Each service has an SLA contract in place for its consumer and tools exist to measure it.
- An Integration Competency center manages SOA in the company and a dedicated budget is associated to it.
Eric: Successful elements I’ve seen at companies are first- people with flexible mindsets and ability to adapt to process changes. Most have had technology that allowed them to automate the governance process and enable federated views of IT assets – not just SOA assets, but a view of the Enterprise – people, processes, and technology/services. The greatest element of success – a champion with a strong business acumen and political relationship with C-level and high managers.
Dave: I would suggest embedding it in other IT and development governance and establishing a consistent set of standards to measure against.
InfoQ: If you could change one thing in SOA, what would it be?
Jeff: Standards... I personally have not followed up to closely on this area, but I would identify that we need to make adoption easy. Further no different than any other area, we need to establish a roadmap with a clear direction for where we are headed. Unfortunately, I view SOA Standards as a “rat hole”. Sorry… If I were involved in a committee, I might not think this way – unfortunately I am not, thus, I have this viewpoint.
Technology would also be an area where it would be helpful. No one likes the idea that a battle exists between Microsoft and Java. Thus, the world is plagued with view of not being united, but divided. While I recognize that there are means to have them work together it doesn’t necessarily unite the world into one SOA.
William: I would convince everybody to do contract first approach and define a unique standard to describe service SLA. I would love to have an open source implementation of a web service management platform.
Eric: Could we have its creation earlier? ;) Seriously, if I could change one thing of SOA, it would be the perceived hit up front. Any change a company undertakes is going to cost the company. Despite 10 years of SOA, IS and business still view SOA as a cost instead of a cost savings for the vast majority. MomentumSI has proven this to customers over and over.
Dave: I would prevent at all cost the dilution of the SOA brand by market hype and hyperbole.
As you can see even after 10 years, it is easy to disagree on some of the approaches and perceived benefits of SOA. How would you have answer those questions?