Todd Biske: Outside the Box

Archive for the ‘Books’ Category

Go figure, just as I post an update on articles, etc., I have another one published. I wrote an article titled, “Implementing SOA Governance” for InfoQ and it has now been published. It’s not a direct extract from my book, more of a short overview of a few of the key points from it. I hope you enjoy it, and if you want to read more, please consider the full book.

A couple of items that I thought I’d call attention to:

1. I wrote an article for the latest issue of Architecture and Governance magazine titled, “Does SOA Really Matter?” My opinion, not surprisingly, is yes. This article requires registration to read.
2. Jordan Haberfield, Senior VP of IT Client Services for System One Holdings, interviewed me for his Agile Elephant blog regarding my book on SOA Governance.
3. Thank you to the people who purchased the book from Amazon today and allowed me to watch my Amazon sales rank go up from somewhere in the 200,000’s to 32,042. While my target audience is a bit more narrow than that of Brisngr, it would be really cool to see the sales rank make it to the four figure barrier.
4. Speaking of Amazon, consider adding to your order the latest book from Patrick Lencioni, “The 3 Big Questions for a Frantic Family.” While this book has nothing to do with IT, Patrick’s leadership fables gave me the inspiration for the style of my book. I can only aspire to become as good an author as he is. I heard him speak at a Gartner summit, and he’s an excellent speaker on top of it.

Keep an eye out for an interview with Loraine Lawson of IT Business Edge. I also plan on doing a few podcasts in the near future to talk about the book, as well. I’ll post information about them here as they come online. Thanks for being a reader of the blog, and please let me know your comments and questions about the book at soagovbook at biske dot com.

I just read David Linthicum’s “Governance Monday” post, Can SOA governance technology be distracting? In it, he discussed some of his conversation with Anne Thomas Manes of The Burton Group. He states that SOA governance technology can “muddy up the water in the early stages” of the effort. I certainly agree with this. These technologies can be complicated, especially when striving for a highly integrated, automated approach. There is a risk that the reason for using the technology can be forgotten as the focus shifts toward getting the technology implemented.

There is another question I would like to address: can governance itself be distracting? While Dave covered the technology angle, what about the governance processes? I did an interview with Loraine Lawson of IT Business Edge last week, and in that interview, I stressed that organizations must avoid starting too late with their governance efforts. If you are adopting SOA to change the way you approach solution development, you need to make the desired behavior known early and often. If you wait until a team “misbehaves” before making them aware of the correct behavior, it will create animosity. If you wait until the situation is critical before embarking on the change associated with SOA, you’ll be forced to take a heavy-handed approach, much as world governments were forced to take heavy-handed actions with current financial crisis. It was necessary, but no one is happy about it.

Want to know more? Check out my book, SOA Governance.

This was too good not to share. Word of my new book on SOA Governance made its way to the Yahoo SOA group this week and Steve Jones had a great comment:

Now as it’s a governance book it should be big, it should be heavy and you should be able to hit people with it. I’m a bit concerned that this one looks a bit fragile and quite frankly a PDF goes against the whole principle of Governance enforcement.
Wait…I’m meant to READ the things?

Yes, the book is paperback, and at just over 200 pages, it won’t do much damage if you beat people over the head with it. Thanks for the laugh, Steve!

Unless you’re completely disconnected from mainstream media, you’ve certainly heard the word “policy” in the news recently. It’s been frequently prefaced with two additional words: “failed economic” as in “the failed economic policies of this administration.” With this, there should be no doubt that there is a connection between policy and governance. Policies are the rules that, if followed, should lead to the desired behavior for an organization. In the case of the current financial crisis, economic policies are ones that should lead to the desired behavior of the economy.

The current situation actually serves as a very good example for a discussion on policy and governance. First off, I’ve yet to hear any of the candidates call out the specific policies that they believe were wrong. The closest that they have come is to attack the deregulation that went on the 90’s. Now, you can argue that deregulation is a policy. In effect, it’s a policy that says, “We’re going to make this domain someone else’s responsibility” and that’s perfectly all right. If your view of governance is that it’s all about decision rights, this is in line with that approach. The policies don’t end there, however. The next policy that could be examined is the lending policies of the institutions that gave mortgages to people who had no hope of ever paying them off. My personal opinion is that this is the failed policy, which wasn’t a policy put in place by democrats or republicans, but by the lending institutions.

Now that the candidates are now trying to offer solutions for the situation, it shows that there are many ways of addressing the fact that the desired economic behavior is not being achieved. We can certainly change the people involved, and I think there’s an underlying assumption that with a change in people, the policies will change too. Second, we can change the policies. In this example, there are two areas for change, however. Changing the policies around regulation only changes who can set the policies around lending. It could be just as easy for a different set of people to keep the same bad lending policies in place. The second area is the lending policies used by the banks. Clearly, changes here would certainly stop the bleeding, so to speak. Finally, we can change the processes. Perhaps the lending policies on paper were fine, but were routinely ignored. Putting more rigid enforcement and auditing in place would be one way of addressing this.

So how does all of this apply to SOA Governance? The same general approach is applicable to the world of SOA governance. If you’re not getting the desired outcome from your SOA efforts, then perhaps you need to look at the policies you have that govern your SOA efforts. Have you “deregulated” your SOA and simply expect your projects to do the right thing? Do those projects care about the greater corporate economy, or are they simply concerned about the project “shareholders” and focused on delivering on-time and on-budget and nothing else? Perhaps the problem isn’t that critical, but the efforts are disjointed. A centralization of policy administration into a Center of Excellence may be in order. Or, perhaps the policies are there, but aren’t being followed, so a change in processes is needed. Finally, it could be in such dire straits that a complete change in leadership is needed. In my opinion, however, it all begins with policies. If you’re not getting the results you want, take a look at the policies you have (or the lack thereof). Either the policies are not yielding the results desired, or the policies are not being followed. If the latter, look at your processes and make changes there. If the former, you need a policy change. Your current SOA leadership can change the policies, or if they are blind to the problems in front of them, then make a change to the leadership to people that will put new policies in place. A change in personnel with no corresponding change to policies or processes is no change, and a change in personnel without an analysis of the policies they will put in place to determine if they will yield the desired behavior will also fail.

Want to learn more about governance as people, policies, and process? Check out my book on SOA Governance available now from Packt Publishing, and from other online book stores soon!

I’m now officially a published author. All of the final edits are done, and my book on SOA Governance is now available via the store at Packt Publishing. It will also be available through amazon.com and other online bookstores. Please consider it as part of your effort to learn about SOA Governance and don’t hesitate to contact me if you have further questions or comments.

At the SOA Consortium meeting, Fill Bowen of IBM asked me a question after my soapbox on SOA Governance that I thought would make a great post. He was surprised that I didn’t mention the words “decision rights” a single time in my post. It’s a great question, especially because the IT Governance book from Jeanne Ross and Peter Weill of MIT’s CISR defines IT governance as “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.”

In all of my posts on SOA Governance, and in my SOA Governance book, I don’t think I’ve talked about decision rights once. While this was certainly unintentional at first, I’ve now given it some thought and I’m happy that I didn’t include it or emphasize this viewpoint. The closest I’ve come is in my discussions around the people component, and stating that the people do need to be a recognized authority. Obviously, recognized authority does imply some amount of decision rights. At the same time, I think that’s emphasizing the wrong thing. There is a negative view around the term governance because people associate it with authorities flaunting their power. The emphasis needs to be moved away from the people, and instead focus on the policies. As I stated in my “Governance does not imply Command and Control” post, if you focus on education, you can allow individual teams to make decisions, because you’ve given them the necessary information to make the right decisions. If they don’t have the information to make decisions that will lead toward the desired behavior, it turns into a guessing game. Not only can there be confusion in what the correct decisions are, there can also be confusion on what decisions should be escalated up the chain. If we instead focus on creating policies and making those policies known so that anyone in the organization can make the right decision, we’re in a much better state. Yes, you will run into some situations with conflicting policies, or the absence of a policy, but if those are the exception, it should be far easier to know that those decisions require escalation or inclusion of others.

During my soapbox derby discussion at the SOA Consortium meeting, I chose to discuss SOA Governance, and I thought that one of the messages I delivered would be another appropriate post to highlight some of the content in my upcoming book.

As I’ve said in this blog, SOA governance is the combination of people, policies, and processes that an organization uses to achieve the desired behavior associated with SOA adoption. This post, not surprisingly , will focus on the process component. Previously, I had a post explaining that governance does not imply command and control. Those two words only bring to mind one of the four processes: enforcement. There are three additional processes that your governance effort must also implement. The four processes are:

• Policy definition
• Education and communication
• Enforcement
• Measurement and feedback

Policy definition is concerned with establishing the policies that the governance team feels will result in the desired behavior if they are followed. Without policy, the rest of the organization must either guess what the correct decisions are to get to the desired outcome, or involve someone from the governance team on every single project. The first option is unlikely to lead to success, and the second option has both scalability issues as well as being prone to variation based upon the “tribal knowledge” of the particular person from the governance team involved. Defining and documenting the policies is step one toward gaining consistency in the outcome.

Education and communication is the next step, not enforcement. Just because the governance team has reached agreement and documented the policies doesn’t mean they’re going to be followed, or even known for that matter. A formal, planned communication effort to educate the organization on why you’re adopting SOA, the desired behavior you hope to achieve, and the policies that are being put in place to achieve them is required. It’s not a one time presentation to all of IT, but rather a series of targeted communications for the various roles in the organization, large group presentations, small team presentations, blogs, wikis, and appropriate surveys and followups to ensure that the communication is effective.

Enforcement is the third step. Even if your communication efforts are incredibly successful, you still need to put processes in place to ensure the policies are being followed. What you will find, however, is the better job you can do on communication and education, the easier your enforcement processes can be. If education is poor, enforcement will likely need to be more heavy-handed. Where possible, automated testing and reporting can certainly make the processes more efficient and cost-effective.

Finally, the governance group must have measurement and feedback processes to ensure that progress is being made toward the desired behavior. If the desired behavior is not reached, something needs to be changed, and it could easily be the policies, the processes, or the people involved with governance. Accountability is lost if the team puts policies and processes in place, but then does nothing to verify that all that effort actually paid off.

I’m here at the SOA Consortium meeting in Orlando. The first speaker at the event was Jeanne Ross from the Center for Information Systems Research at the MIT Sloan School of Management. They had recently completed a study on SOA adoption, and she presented some of the findings to the consortium. If you’re not familiar with Jeanne Ross, I thoroughly recommend two of her books, IT Governance and Enterprise Architecture as Strategy. I continue to refer to some of the concepts I learned from these books as part of my day-to-day job.

One of the interesting takeaways I had from Jeanne’s presentation was the information on the value companies are getting out of reusing services. What the study has found is that while there is definite measurable value that comes out of reuse, in many cases that effort comes at a very significant cost, a cost that often usurps the value generated. This made me think about a discussion that I frequently have with people concerning “enterprise” services versus “non-enterprise” services. In these discussions, it’s always been a black-or-white type of discussion where my stance is that we should assume a service has the potential to be an enterprise service unless told otherwise while the stance of the person I’m speaking to is frequently the exact opposite. It turns out that neither of these positions is the right way.

If you took my old stance, the problem is that you incur costs associated with building and operating a service. If that service doesn’t get reused, you won’t recoup that cost. If you took the opposing stance, you avoid the initial cost, but then you’re at risk of incurring an even higher cost when someone wants to reuse it. To maximize the value that you get out of your services, we need to find something in the middle. There does need to be a fixed amount of cost that will get sunk into any service development effort, but it needs to be focused on answering the question of whether or not we should incur the full cost of making it an enterprise service with full service lifecycle management, or if we should simply focus on the project at hand and leave it at that. I’m going to give this topic more thought and try to determine what that fixed cost should be and hopefully have some future blog entries on the subject. In the meantime, if you have ideas on what you think it should be, please comment or trackback. I’d love to hear more on how others are approaching this.

I can finally let my secret out. For the past few months, I’ve been working on my first book, SOA Governance, and I’m now happy to say that it is available from my publisher, Packt Publishing. It can also be purchased from Amazon.

If you’ve followed this blog, you’ll know that my take on SOA governance is that it’s all about using people, policies, and process to achieve a desired behavior, and that same theme carries through the book, showing how it applies to all aspects of your SOA efforts, ranging from project governance, to run-time governance, and finally to what I call pre-project governance.

The style of the book is inspired by the great books of Patrick Lencioni, including Five Dysfunctions of a Team, Death by Meeting, and Silos, Politics and Turf Wars. In it, he presents a fable that illustrates the concepts and points. In my book, I present the story of a fictitious company, Advasco, and their journey in adopting SOA. Along the way, the book analyzes the actions of Advasco and the role of SOA governance in the journey.

Please check it out, and feel free to send me your feedback or questions. I hope it helps you in your SOA efforts.

I had the opportunity to attend a great presentation from Stephen Young, Founder and Senior Partner of Insight Education Systems. The talk was around the concept of micromessaging, which can be further broken down into MicroInequities and MicroAdvantages. To understand these, Stephen started with the difference between denotation and connotation. Denotation represents the words we use, while the connotation behind those words reveals the true meaning of what is being said. This can involve body language, inflection, tone of voice, and much more. As he pointed out, humans (or humanoids) have been communicating for hundreds of thousands if not millions of years. The written word has only been around for a fraction of that time. Therefore, so much more about how and what we communicate is conveyed by more than just the words. He did an exercise with us where we tried to describe what a dog does when it is happy. While most dog owners know within a fraction of a second the mood of their dog when they walk in the door, trying to convey that recognition process to someone else solely through words is incredibly difficult. In other words, our brains are very well tuned to picking up on things outside of the words in a conversation.

Getting back to the concept of micromessaging, MicroInequities are all of the very small things that we do in a conversation that have negative connotations, such as folding your arms, losing eye contact, giving a “ho-hum” response to the work of some individuals while lavishing excessive praise to others when the outcome of each was similar, etc. In contrast, MicroAdvantages are positive micromessages. The FAQ at the Insight Education Systems page does an even better job of explaining this. A very simple example of MicroInequities was the use of apologies in the workplace (and elsewhere). How often have you heard someone say, “If I offended you, I’m sorry.” Right off the bat, the use of the word “if” makes it a qualitative apology, and not a sincere one. Stephen said, “If you step on someone’s foot, do you say, ‘If that hurt, I’m sorry?’ No, we simply say, ‘I’m sorry.'” He used the example of Michael Nifong, the former attorney in the Duke lacrosse team case. His apology contained this:

To the extent that I made judgments that ultimately proved to be incorrect, I apologize to the three students that were wrongly accused. I also understand that, whenever someone has been wrongly accused, the harm caused by the accusations might not be immediately undone merely by dismissing them.

Analyzing this, we see that the apology immediately starts out with a qualifier. It then uses the terms “that ultimately proved to be incorrect” which connotes “I still think I was right.” His apology is only directed at three students, who he does not name, which excludes the impact to Duke University, the coach who lost his job, the team who lost their season, the families of the players, etc. On top of that, he didn’t even show enough respect to mention the players by name. The gist of this was that apologies should be about the impact, not the intent.

The talk went on to demonstrate the impact of our body language when listening and how it causes speakers to behave differently even when conveying the same or similar information, as well as the differences (and similarities) in different areas of the world. Already today, I have stepped back and adjusted the wording in an email I was composing as a result of this talk. I plan on putting his book on my Amazon wish list and encourage all of you to do the same, and, if you have the chance, hear him speak or bring him to your organization for a workshop.

James Urquhart brought to my attention the public review of SOA Patterns, as authored in the forthcoming book, “SOA Design Patterns,” by Thomas Erl. You can see the press release from Prentice-Hall here.

My first reaction when I received the email, prior to visiting the SOAPatterns.org site was one of skepticism. While I think patterns can add a lot of value, the immediate problem I saw stems from the fact that I’m very much a believer in business-driven SOA. In order to reach a broader audience across multiple verticals, you have to be more business agnostic. As we get more business agnostic, we naturally move deeper into the technology stack, and things at that level of granularity may not be the best service candidates, although they may be great candidates for reusable frameworks. If we’re talking about patterns inside of the service implementation, then we’re really talking about general design patterns, building on the original work of the Gang of Four, not really SOA Design Patterns.

So, with my bias set, I visited the web site. The first thing I hoped to see was some classification by business industries, such as “SOA Patterns for Insurance” or “SOA Patterns for Health Care” but I didn’t find them. Bummer, but I also didn’t expect this. Something like that would be of significant value as intellectual property to a consulting firm, and I think they’d make a lot more money keeping it to themselves and leveraging it on their engagements. What was on the site was four chapters: Basic Service Inventory Design Pattern Language, Architectural Design Patterns, Basic Service Design Pattern Language, and Service Design Patterns.< ?)>

In looking at the first chapter, Basic Service Inventory Design Pattern Language, my first reaction was again one of skepticism. The first page begins with “Inventory Context Design Patterns,” “Inventory Boundary Design Patterns,” “Inventory Structure Design Patters,” and “Inventory Standardization Design Patterns.” It also introducted a phrase- “service inventory architecture” -which I had never heard before. Looking at this page, nothing was making a connection with me. As I drilled into each section, I did find some goodness, but it could be argued that what is really being presented in this section is really a description of a step in a methodology, rather than a pattern. For example, one pattern listed is the “Enterprise Inventory” pattern, which lists the problem as:

Delivering services independently via different project teams across an enterprise establishes a constant risk of producing inconsistent service and architecture implementations, compromising recomposition opportunities.

The solution is:

Services for multiple solutions can be designed for delivery within a standardized, enterprise-wide inventory architecture wherein they can be freely and repeatedly recomposed.

This doesn’t feel like a “pattern” to me, but it’s certainly something that should be done. I don’t think anyone would argue that having an enterprise service inventory is a bad thing. Another pattern I looked at was the “Vendor-Agnostic Context” pattern. Again, what was presented in the “pattern” was goodness, however, it felt more like a principle rather than a pattern. This particular one did do a good job in demonstrating how this principle does lead to the use of specific techniques, such as leveraging the “Canonical Protocol” and “Decoupled Contract” patterns.

Overall, what did I think? Well, it certainly didn’t meet my original hope of seeing industry-specific business patterns. By that, I mean I didn’t find something that said “Order to Cash” with guidance on the types of services that should make up that process. I didn’t find something that said, “here are services that all organizations with an HR department should have.” Nothing business-specific whatsoever. Of course, I didn’t expect to see this, it’s just what I was hoping to see, just as I hoped the (defunct?) SOA Blueprints effort from OASIS a couple years ago might produce something along these lines.

Putting that bias aside, the more I dug into the site, the more I found things that provided good guidance, even though I’d say the use of the “pattern” moniker was a bit liberal. If you want to get an idea of what principles and factors should be considered in creating good services, versus just slapping WSDL or XML schemas in front of some existing logic, there’s a lot of good material here that is freely available. While some of the earlier pages read too much like a college textbook, a couple drilldowns brought me to things that were applicable to my daily work and made sense. So, based on that, I would recommend that people at least visit the patterns site, drill down into it, and see what nuggets you can leverage in providence guidance to your service development teams. If you really like it, then perhaps Thomas’ book can become part of your standard library for your developers.

On Wednesday, Patrick Lencioni, author of The Five Dysfunctions of Team, and other management fables gave the morning keynote. It was an excellent talk. Having read both Five Dysfunctions and Silos, Politics, and Turf Wars, I recommend picking up all of his books if you have an interest in making your organization work better (and you should). I picked up his latest book, The Three Signs of a Miserable Job and Death by Meeting after his session and had a nice conversation with him about some experiences.

I found this podcast fascinating. Dr. Moira Gunn speaks with Sandra Blakeslee about the body maps our brain creates and gives some very interesting anecdotes regarding virtual reality, out of body experiences, phantom limbs, and even treatment for anorexia. I plan on getting Sandra’s book after this fascinating interview.

I was recently sent a copy of “SOA and WS-BPEL” by Yuri Vasiliev and Packt Publishing for review. The book is subtitled, “Composing Service-Oriented Solutions with PHP and ActiveBPEL.” After reading the book, the subtitle is much more accurate than the primary title. The book is first and foremost a guide for constructing Web Services using the SOAP extension for PHP and building BPEL processes using ActiveBPEL. Secondarily, there is a discussion behind the principles of SOA and WS-BPEL. Clearly, the right audience for this book is the developer community. If you’re removed from day to day coding, the book may not be as valuable.

If you’re looking for hands-on examples, this book has plenty of them. It includes all of the building blocks necessary from building your first service in PHP to creating an orchestrated process using BPEL. I felt that there was more emphasis on the coding efforts than necessary, however, and not enough on some of the theory behind it. This was evident in some of the early examples. In the sections on PHP, the examples result in a service that stores an XML representation of a purchase order in a database. The examples in the book take the incoming XML, create a PHP array representation of the XML, then convert it back to a DOM representation for storage in the database. While I do not know whether this approach was due to a limitation of the SOAP extensions, as an architect, it left me shaking my head. If the service is simply a pass-through to a database, there’s no reason to take all the time to parse the XML, bind it to some internal data structure, and then turn that internal data structure back into XML. Continuing on, the example then added XML schema validation to the mix, but it was performed by a stored procedure in the database. If you understand the role XML Schema validation has in security, odds are that XML schema validation will have occurred long before we even reach the back end database.

The section on WS-BPEL followed a similar vein. The bulk of the book was simply focused on walking you through the steps necessary to perform the actions in ActiveBPEL, rather than on building a sound understanding of WS-BPEL. There were pages upon pages of instructions on what menus to select, items to click, etc. I was very surprised at the lack of screenshots or graphical representations of the processes in the book. More often than not, they recommended using the Source tab in ActiveBPEL to compare the BPEL document in the book to what should have appeared after going through all the actions. My personal view on BPEL is that I don’t ever want to see it. I want to leverage the modeling capabilities of any BPM tool, and let the tool worry about BPEL behind the scenes.

Overall, for a book heavily focused on the developer community using PHP and ActiveBPEL (somewhat of a narrow audience, in my opinion), it’s certainly a good walkthrough to get your feet wet. It’s not going to give you the architectural skills you need, but it will move you through a lot of material very quickly. For people who are quick studies and just want some solid examples, you may find this a decent investment. For someone looking for more theory and architectural principles behind SOA and WS-BPEL, I’d probably look elsewhere.

Disclosure: This book was provided to me at no cost for the purposes of reviewing it. If you’re interested in having me review a book, please contact me at todd at biske dot com.