Executing SOA: An Interview with Robert Laird and Tilak Mitra
Executing SOA: An Interview with Robert Laird and Tilak Mitra
Join the DZone community and get the full member experience.Join For Free
The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
Earlier, we reviewed the excellent book Executing SOA: A Practical Guide for the Service Oriented Architect from IBM Press. I recently had the opportunity to discuss the book and SOA in general with Robert Laird and Tilak Mitra, two of the authors of the book. It turned out to be an insightful dialog which surfaced real world experiences, continuing the practical theme of the book.
Aslam Khan: What was your motivation for writing the book?
Robert Laird: When working with customers, I was getting very similar questions from them concerning SOA Governance, for example. I wanted to get these questions answered, and the book seemed like a great vehicle to help address some common patterns.
Tilak Mitra: There has been a lot of talk about using a proper and disciplined approach to the identification, specification (detailed design) and realization (implementation decisions) of services in a SOA. But the industry has been lacking a formal approach to this discipline of service modeling and architecture. We wanted to formalize such a technique and share that with the community, so as to foster a consistent approach to service modeling and design.
Khan: I found that the book focused on two groups - the business architect and the software architect. Was that intentional or did it arise as a natural explanation of the practical approaches necessary for building a SOA?
Laird: We intentionally wanted to raise the profile of the business architect and the role of business in general as a key success factor for real SOA. The software architect is very important also, but you're going to get that as a matter of course in any decent SOA book.
Mitra: We wanted to highlight the fact that SOA is as much a business imperative as it is for IT. Hence, a business architect that understands the business domain, the enterprise constraints, the business vision and imperative along with the business goals - and demonstrate the incorporation of all of these into a single unified business architecture, is critical. The business architecture then is understood, rationalized and transformed into an IT architecture based on SOA principles, policies, best practices and guidelines. The key linkage between the business and IT is manifested by the transition and traceability between the business architecture and the IT architecture. Hence both the business and the SOA architect are equally important for a successful SOA.
Khan: In the book, you mention that a lot of the practices have been garnered from experiences with real-world projects. How wide did you cast your net?
Laird: We are all part of IBM groups that perform consulting on a world wide basis. For example, on governance, we used experiences from Japan, Australia, South Africa, the European Union, the Middle East, and North America. In addition, one of our authors has 25 years of industry experience at a U.S. telco and those experiences also helped to shape the book.
Khan: SOA Governance seems to be very bureaucratic in its nature. How does this fit in with teams that focus on simpler structures that support their agile methodologies?
Laird: First, I don't agree with the premise of the question that governance is necessarily bureaucratic. Using tooling for automation and sizing the governance for the task at hand should allow for an agile governance. But you are certainly correct that it can become bureaucratic if not led effectively. The trick is, whether it's for agile or waterfall or whatever, to only do the governance that makes sense and adds value. In particular, for agile methodologies you wouldn't want a control gate for certain aspects of the development lifecycle such as requirements, since agile will elicit requirements quite well via frequent user interactions. But you still need to validate that the developers have followed standards, policies, and prescribed patterns. But automate, automate, automate!
Khan: In your experiences, what are the areas that appear to be challenging most teams embarking on a SOA project?
Laird: Most organizations really don't know how to get started and end up in analysis paralysis for a year or two while performing 'business as usual'. I'm coming to the conclusion that it makes sense to setup a 'tiger team' for that first project and seed that team with some of the best and the brightest from within the organization and spice the team up with some very experienced consultants. And, of course, good SOA middleware from IBM!
Mitra: A deep understanding, acknowledgement and a subsequent adoption of a proper design methodology to identify the right services in an SOA is absolutely critical to realize the true business benefits of SOA. Adopting a formal method for service design is critical.
Khan: What are the typical mistakes that you see recurring in SOA projects?
Laird: Lack of business input with the business seeing SOA as an 'IT thing'. As a result, the business abdicates all responsibility and knowledge and SOA is not likely to succeed in such an organization. To me, those business leaders are dinosaurs and need to move aside for those who do have the intelligence, leadership, and drive to make a difference.
Mitra: Thinking of SOA governance in hindsight is a recipe for failure. A lean SOA governance mechanism should be put in place soon after the pilot phase of SOA is completed. This governance mechanism can then be subsequently matured over time, based on the enterprise maturity in SOA adoption.
Khan: For the software architect and software developer, what are the main impedances between the SO and OO paradigms?
Laird: It's all about granularity. OO developers and architects are used to working at a technical granularity while SO developers / architects must work at both a technical, but more importantly, a business granularity. That's a step up the value chain for them, and requires a certain level of business knowledge that they're not necessarily going to have or be able to get easily.
Khan: Your book wraps up with a tantalizing collection of short snippets on the future of SOA. Which of those do you think will have the biggest impact in the long term?
Laird: Really, there's a common thread to Chapter 8, and that's that innovative ideas can come from anywhere, and we want to position the organization to be able to take advantage of that. It could be Software as a Service (SaaS), Web 2.0, an employee idea on a better business process, an idea from anywhere in the world, or some new capability that won't appear for another 5 years. Those ideas will come and go, but flexibility will always be beneficial in the short, medium, and long term.
Khan: Following up from SOA Compass, this is yet another excellent book (in my opinion). What is next on the horizon?
Laird: You are clearly a very intelligent reviewer, thanks :-). Robert and Tilak have a book coming out that is dedicated to the subject of SOA Governance with co-authors Bill Brown and Clive Gee. This book will be published by IBM Press, and is scheduled for release in late 2008. The intent is to not only explain what SOA Governance is, but to also explain how to go about creating a world-class governance capability for our customers and to show IBM’s leadership in this area.
Khan: Many thanks to both of you for your time, and your contributions to the SOA community.
This chapter (http://architects.dzone.com/sites/all/files/0132353741_Sample.pdf), A Methodology for Service Modeling and Design, is excerpted from the new book, Excecuting SOA: A Practical Guide for the Service Oriented Architect (http://www.ibmpressbooks.com/title/0132353741), authored by Norbert Bieberstein, Robert G Laird, Dr. Keith Jones, and Tilak Mitra, published by IBM Press, May 2008, ISBN 978-0-13-235374-8, Copyright 2008 Pearson Education, Inc.
Opinions expressed by DZone contributors are their own.