Major figure in the SOA field, Thomas Erl is a best-selling IT author with books such as SOA : Principles of Service Design or SOA : Design Patterns . He is also the founder of SOASchool.com and CloudSchool.com. He offers us the huge privilege to answer some questions, transcribed on Think Service.
You are one of the authors of SOA Governance: Governing Shared Services On-Premise and in the Cloud. Could you explain SOA governance and what it provides?
Basically SOA governance, provides a formal means of regulating and evolving the entire SOA project lifecycle – from the beginning when we plan an SOA adoption project, to the actual modeling and conceptualization of the services, to their typical designs, their implementation, and then through the subsequent stages where we deploy and use services, and perhaps then further need to refine them in response to evolving processing requirements. So what SOA governance gives us is the ability to establish controls that help standardize and guide all of these efforts from the very beginning.
We need clear direction to work toward the target state promised by an SOA adoption project. SOA governance gives us rules, standards, guidelines, and just a lot of control over how we carry out the entire SOA project lifecycle. SOA governance is a critical part of getting the most out of the long term value of SOA projects Governance allows us to plan for longevity – of the architectural model we put in place, of the services we plan to build, and of the plan to leverage that model, which allows us to build our projects in broader terms, to structure them and establish an ecosystem.
Governance itself is not something specific to SOA, we’ve had various types of IT governances systems and approaches throughout IT history.
You created the MSOAM (Mainstream SOA Methodology), could you tell us more?
It’s good to make a distinction between governance and methodology. With governance we put in regulatory policies and standards and all of these different control points that require levels of compliance based on what we are delivering.
With methodology we’re referring to the actual method. So we choose a methodology that works with how we want to approach the delivery of services, or how we want achieve our target state. A methodology essentially gives us a formal process of accomplishing that. It’s a process by which we carry out an SOA project in compliance and with the support of the overarching SOA governance system.
The Mainstream SOA Methodology is intentionally generic. It’s actually a generic set of methodologies that became common in the SOA industry and that are important to understand and contrast to one another because they each have their own set of requirements that help us determine what approach is best for our particular goals.
What the “mainstream” label refers to is that it’s intentionally generic, comprised of proven steps and techniques. It’s meant to be generic so that organizations can bring it in-house as a starting point and further augment and customize it. So no matter how the Mainstream SOA Methodology is set up, top-down or bottom-up, you can choose an approach and you can then take it and further customize it, incorporating perhaps other methodologies or other preferences you have that are unique to your organization.
So in a way, the SOA Governance book we just published a few months ago, establishes a Mainstream SOA Governance System, the same way that previous books established the Mainstream SOA Methodology.
There are two main delivery processes, the top-down and the bottom-up approach. Don’t you think the bottom-up approach is just usable for a short-term vision with a fast ROI?
That isn’t usually the reason it’s chosen. There’s a good diagram that we use and it’s in the back of the SOA Principles book. It shows the way that we can better assess the impact of choosing the top-down approach or a bottom-up approach or something in between, by understanding expectations and trade-offs.
The bottom-up approach will get you to your services and your solutions faster than the top-down approach because you’re just focusing on immediate tactical requirements; so once you get to the point where you actually build something, it can still incorporate an extent of service-orientation.
What we usually are not able to do with the bottom-up approach is spend time modeling the services in advance and in relation to other services that exist within in a given boundary (or what we call a service inventory). When we follow a top-down approach we tend to allocate more time to up-front analysis. You have the opportunity to look at the range of services you are planning to deliver for a given domain and you can model those out in advance as to avoid services overlapping their functional boundaries. You can get a better idea of what the reuse potential would be of those services and you can also get a better understanding of their appropriate functional granularity.
A lot of that can be better refined with up-front analysis before you actually move to contract design and build your services. But again, that takes more time and more initial investment, which is why some organizations try to find a balance between top-down and bottom-up.
In 2009 you created the SOA manifesto with other authors like Anne Thomas Manes. What is the goal of this manifesto?
The SOA manifesto was something that I wanted to do for some time but it was difficult to get all the right people to come together at the right time.
In 2009 when we had the international SOA & Cloud Symposium occurring in Rotterdam, I had started a dialogue with a number of people in the industry that I felt were the most suitable in terms of expertise and their contributions to the SOA community. Some of them represented vendors, others were published authors and known scientists in the area. I contacted some of these individuals, and they invited others and we ended up with about a dozen or so members who came together to meet in Rotterdam. Over the course of those two days we put together a declaration of what the underlying values and objectives of SOA are.
All of this was inspired by the Agile manifesto which is about 10 years old now, and was something that became valuable to the Agile community. Basically the main purpose of the SOA manifesto is to provide clarity about what is and is not SOA and also, very importantly, clarify the distinction between SOA and service-orientation in a very concise format.
It’s something that can act as a communications tool for a range of IT people, from management to analysts, to architects, and so on. IT professionals can basically just get at the core of what constitutes service-oriented architecture and service-orientation. The way that it’s documented is that we highlight each priority and describe what it is we are trying to accomplish. By having this prioritization it also helps us understand what and how the priorities can better relate to our business requirements and goals.
So going back to your previous question about top-down versus bottom-up: we’re looking to achieve an environment that will have long-term benefits for the organization; something we can use to repeatedly leverage benefits for years and decades to come. And so that needs to be a goal that works with our business goals. If our business goals do not support that, then we can use this information to decide whether or not SOA adoption is the right choice for our IT enterprise.
We have priorities that basically communicate the underlying values of SOA and service-orientation and then we have a number of guiding principles that came out of the discussion that are now there to help guide practitioners to achieve those values and priorities.
In 2009, Anne Thomas Manes wrote a post on her blog: SOA is dead, long live to services. She thought that the technology debate was too important (what was the best ESB or Web services vs. REST…) and that people forgot the main thing: architecture and services. Do you share this opinion?
This was prior to the SOA Manifesto. At the same event in Rotterdam where she co-authored the SOA manifesto Anne did a talk about the Resurrection of SOA; about how the community needs to know and revive the acronym SOA and give it actual meaning.
What had happened up until that point leading up to her blog post was that the acronym and term (“SOA” and “service-oriented architecture”) were just being used so much that there was too much ambiguity associated with them. There were many different definitions from different vendors and practitioners, and so on. So much disparity in meaning had been given to it that it had lost any specific meaning whatsoever, to the point of becoming meaningless. There was nothing left for the community to really understand because, for many, SOA had lost its identity.
In a way her blog was one of the things that helped bring back the idea that we really did need an SOA manifesto to be established, to give it clarity and provide some clear understanding of what it is and what it means. Her blog really tried to shake things up, and I think it helped. It was what I like to refer to as an intervention; she stepped in and said this is not going anywhere, there’s so much potential here, so much that organizations can benefit from, but the industry is going down the wrong path and we’re losing the opportunities to really take advantage of this innovation, in terms of the methods, the architectural model, and so on. Looking back, it was something that helped bring about positive changes in the industry.
We do need to define the architecture and we need to distinguish it and, you know, it comes down to actually giving it a proper definition. We have an architectural model with specific characteristics and that’s what classifies it as being service-oriented. We have a paradigm in service-orientation comprised of specific principles and when you apply those you shape software programs so that they have specific characteristics. We can then legitimately consider those programs as services. The architectural model has it’s own characteristics to support the assembly of those services in order to achieve the target and maintain it and prepare it for the future. All of this is now well documented in books, in articles and, of course, the manifesto contributed to that.
Now that you’ve released the SOA Governance book, you have others books in preparation, such as Cloud Computing: Concepts & Technology, SOA with REST, Service-Oriented Infrastructure, Next Generation SOA and SOA with Java, could you tell us more? And also how do you see the future of SOA ?
SOA is in a very strong situation right now because there’s been so much advancement in the area of service technology. In particular, one of the areas that has become important to SOA is the emergence of cloud computing and cloud-based platforms. The ability to move data and deploy servers in remote cloud environments allows us to go beyond the limitations of on-premise infrastructure to design and scale an SOA that incorporates those resources. What that really does is increase the potential for us to realize the target state and the potential to benefit from applying service-orientation, especially in relation to availability and reliability.
So in a sense, it is an option for not just the larger organizations with a powerful infrastructure but also for small-to-medium sized organizations that don’t have the budget to put in a proper infrastructure. They can now leverage cloud resources and cloud-based shared services.
That’s one example, another example of innovation that’s supporting SOA service-orientation is in the area of semantic Web technology. I just spoke a couple weeks ago in Washington at a DoD conference that was dedicated to SOA and the Semantic Web, specifically semantic web technology, and that conference was all about how semantic technology can be used to add more meaning and more substance to services.
Could you talk about Arcitura Education, SOA School and Cloud School?
Arcitura Education is the new parent organization to SOA systems. SOA systems has been around for 14 years now and it was responsible for developing the curriculum and the certification programs that comprised the SOA Certified Professional (SOACP) program from SOA School. Arcitura Education is a parent entity to SOA school and the newly launched Cloud School, which represents the Cloud Certified Professional (CCP) program. Both programs are strictly vendor-neutral. Cloud School has a curriculum of 15 courses and exams in comparison to SOA School’s 23 course modules and exams.
There are additional schools and programs in the planning stages. Many courses are tied to the Prentice Hall Service-Oriented Computing Series from which we use textbooks as official parts of the curricula. There is strict governance in terms of the notation, the terminology, and the definitions so that you can mix and match courses from different programs and still have consistency in the content, which is something people are doing of course. Because SOA and Cloud Computing are closely related, there are custom workshops where these courses are combined. With either school there are workshops we deliver around the world. We also have a very comprehensive self study division where people anywhere in the world can order self study materials and prepare for the exams remotely. They can then take the exams at their local Prometric testing centers.
A big thanks to Thomas Erl and Ivana Lee !