Todd Biske: Outside the Box

Archive for December, 2009

Back in March of this year, I asked “Is Twitter the cloud bus?” While we haven’t quite gone there yet, Tibco has run with the idea of Twitter as an enterprise messaging bus and announced Tibbr. This is a positive step toward the enterprise figuring out how to leverage social computing technologies in the enterprise. While I think Tibco is on the right track with this, my pragmatist nature also sees that there’s a long way to go before these technologies achieve mainstream adoption.

The biggest challenge is creating the robust information pool. Today, the biggest complaint of newcomers to Twitter is finding information of value. It’s like walking into the largest social gathering you’ve ever seen and not knowing anyone. You can walk around and see if you overhear someone discussing something interesting, but that can be a daunting task. Luckily, however, there are millions of topics being discussed at any given time, so with the help of a search engine or some trusted parties, you can easily begin to build the network. In the enterprise, it’s not quite so easy.

When looking at information sharing, here are two key questions to consider:

• Are new people receiving information that they would not otherwise have seen, and are they contributing back to the conversation?
• Are the conversation groups the same, but the information content improved in either its relevance, timeliness, quality, preservation, or robustness?

If the answer to both of those is “no”, then all you’ve done is create a new channel for an existing audience containing information that was already being shared between them. Your goals must be to enable one or more of the following:

• Getting existing information to/from new parties
• Getting new information to/from existing parties
• Delivering more robust/higher quality information to/from existing parties
• Delivering information in a more timely/appropriate manner to existing parties
• Making information more accessible (e.g. search friendly)

The challenge in achieving these goals via social networking tools begins with information sources. If you are an organization with 10,000 employees, only a small percentage of those employees will be early adopters. Strictly for illustrative purposes, let’s use IT department size as a reasonable guess to the number of early adopters. In reality, a lot of people IT will jump on it, as will a smaller percentage of employees outside of IT. A large IT department for a 10,000 person company would be 5%, so we’re looking at 500 people participating on the social network. Can you see the challenge? Are these 500 people merely going to extend the conversations they’re having with the same old people, or is the content going to meet the above goals?

Now comes along Tibbr, but does the inclusion of applications as sources of information improve anything? If anything, the way we’ve approached application architecture is even worse than dealing with people! Applications typically only share information when explicitly required by some other application. How many applications in your enterprise routinely post general events, without concern for who may be listening for them? Putting Tibbr or any other message bus in place is only going to be as valuable as the information that’s placed on the bus and most applications have been designed to keep information within its boundaries unless required.

So, to be successful, there’s really one key thing that has to happen:

Both people and applications must move from a “share when asked” mentality to a “share by default” mentality.

When I began this blog, I wasn’t directing the conversation at anyone in particular. Rather, I made the information available to anyone who may find it valuable. That’s the mentality we need in our organizations and the architecture we need in our applications. Events and messages can direct people to the appropriate gateway, with either direct access to the information, or instructions on how to obtain it if security is a concern. Today, all of that information is obscured at a minimum, and more likely locked down. Change your thinking and your architecture, and the stage is set for getting value from tools like Tibbr.

Full disclosure: I was provided a review copy of this book by the publisher free of charge. From the back cover: “Cloud Computing as SOA Convergence in Your Enterprise offers a clear-eyed assessment of the challenges associated with this new world–and offers a step-by-step program for getting there with maximum return on investment and minimum risk.”

My review in a nutshell: This is a very well-written, easy-to-read book, targeted at IT managers, that provides a robust overview of Cloud Computing and its relationship to SOA, and the core basics of a game plan for leveraging it.

This book was an extremely easy read, which is to be expected of any book from Dave, based upon the easy to read style of his InfoWorld blog. He provides a taxonomy of cloud offerings, extending the typical three categories (Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service) to eleven. While some may think eleven is too many, the fact remains that a taxonomy is necessary as a core starting point, and Dave provides solid definitions for each category that an organization can choose to use. He goes on to provide a financial model to consider for making your cloud decisions, but correctly states that cost is only one factor in the decision making process. He provides the other dimensions that should be associated with your decision making process in equal detail. In chapters 5 through 10, he walks through steps associated with moving services, data, processes, governance, and testing into a cloud environment. Dave’s steps for these chapters are very straightforward. That being said, Dave does not sugarcoat the fact that these steps are not always easy to do, and your success (or lack of it) is highly dependent on how large of a domain you choose to attack.

For someone who has researched SOA and Cloud Computing in detail, this book may not provide a lot of new information, but what it does provide, is a straightforward process for organizing your effort and making progress. Often times, that can be the biggest challenge. For this reason, I do think the book is more geared toward the management side of IT, and less so toward the technical side (architects and developers), but as an architect, I did find the taxonomies presented valuable. The only area for improvement that I saw would have been a stronger emphasis on the role the service model must play in the selection process, and stronger emphasis on having service managers inside your IT organization. Dave discussed both of these topics, however, to make stronger ties between SOA and Cloud Computing (or even ITIL and Cloud Computing), these points could have been emphasized more strongly. Choosing the right cloud provider requires that you have solid requirements on what you need, which comes from your service model. Ensuring that your requirements continue to be met and don’t get transformed into what the service provider would prefer to offer requires solid service management on your side.

Any cloud computing initiative will require that everyone involved have a base level of understanding of the goals to be achieved and the process for doing it. This book can help your staff gain that base understanding.

Mike Walker has had a series of good posts recently on the subject of architecture review boards, but this one in particular, which focuses on governance, caught my attention. In my SOA governance book, I made the obligatory analogies to municipal/federal government in the first chapter, but I didn’t go so far as to compare it directly to the three branches of government here in the United States. I’ve thought about doing this, but never quite put it all together. Thankfully, Mike did. In his post, the following parallels are drawn:

• An architecture review board (ARB) is analogous to the Judicial arm of the US Government. It reviews individual projects and has the power to decline progress of those projects. Mike also adds that it performs enterprise wide decision making, but more on that later.
• An architecture guidance team (AGT) is analogous to the Legislative arm of the US Government. It sets principles and policies, creates standards, and oversees the technology lifecycle.
• Architecture Engagement Services (which typically includes the EA team) is analogous to the Executive arm of the US Government. It defines strategy, designs the enterprise architectures, and performs IT portfolio management.

I had some good conversations with my colleagues on this post and wanted to raise up some of the topics here. First, let’s come back to the role of the ARB/judicial branch in decision making. The ARB doesn’t make architecture decisions, the ARB verifies whether or not the decisions made by the project team follow the law. The only decision the ARB should make is whether the project can proceed forward or not. Mike goes on to state that there should be a clear separation of duties, and that senior IT decision makers should be in the ARB, while the AGT should be filled with SME’s. In my experience, this is normally not the case. I’ve typically seen approaches where the membership of these two groups overlaps significantly. I think this is directly attributable, however, to the effectiveness of the AGT.

One of my pet peeves is when the expectations of a review are not clear. Expectations are unclear when the policies and standards either don’t exist, aren’t widely communicated, or aren’t sufficient. When we get into these grey areas, a group solely focused on enforcement of standards will struggle. In other words, if there’s no laws that apply, one of two things will happen. One, you’ll get an “activist judge” who will interpret the law according to their own opinions, effectively setting policy rather than enforcing the law as written. Second, you’ll go by the letter of the law and deem the space to be uncovered, and as a result, the project can do whatever it wants. Most organizations don’t want the latter, so to hedge their bets, they put the policy makers as judges so they can provide new policy on the fly. That doesn’t bode well, in my opinion, because it now creates an environment where project reviews are likely to be painful, as the things called out will be based on the opinions of the review board, which are undocumented and cannot be anticipated, rather than on the standards of the company, which are documented and can be anticipated by a project team.

The second area I wanted to call out was the separation of the legislative effort from the executive effort. I really liked this separation, and just like an ineffective AGT impacts the ability of the ARB to do its job, an ineffective executive branch will make the AGT ineffective. Mike states that the AGT should consist of technology SMEs, and I agree with that, to a point. The inherent risk is that technology experts (and I’ve been in that role and probably guilty of this at times) can get caught up in advancing their technology rather than executing the strategy. If the AGT isn’t first focused on creating policies and standards that realize the strategy, they will be at risk of hitting gridlock in areas where multiple solutions exist. Take the current health care debate. The strategy has been made clear by the executive branch. If the legislative branch focuses too much on individual party ideology rather than on the strategy of establishing universal health care, gridlock will ensue (except that in this case, one party has a super-majority). The same holds true in the enterprise. Technology advocates can wind up in endless debate on their preferred platforms and completely lose sight of the strategy. At the same time, if the strategy is vague, then there’s no way the legislative branch can do its job. The AGT could set out to establish enterprise standards, but if the executive team isn’t clear on where enterprise standards should exist and where they should not, the wrong areas can be targeted, making adherence to those standards a challenge.

In short, I really like the three-branch model of governance proposed by Mike. It’s a triangle, the strongest structure. It’s strongest when each leg is the same length, working in balance. Make one of those legs smaller, and the other two must lengthen to pick up the slack. If your governance efforts are effective in all three areas, you will have a very strong architecture. If your efforts are ineffective in just one of these areas, you may have your work cut out for you.

In this blog on IT Business Edge, Dennis Byron discussed Facebook as an enterprise software company. His thoughts were based on a keynote address from Chris Hughes, co-founder of Facebook, given at the 2009 annual National Association for Multi-Ethnicity in Communications conference. Dennis stated that Chris indicated that Facebook is much more business friendly than what may have been the perception just two or three years ago. After reading it, it was my opinion that the position being advocated was the use of Facebook, as is, for corporate purposes. That already occurs today, but primarily as another B2C channel, used by marketing types. There are some pioneers out there doing more, but of the ones I’ve seen, it’s all about the customer/potential customer community.

In my opinion, viewing Facebook solely as a marketing/customer support channel is seriously limiting its use to an enterprise. The conversation should begin with an analysis of the communities that can be supported. Guess what? There’s a looming community with a very complicated social structure that exists within the walls of the company. Why can’t tools that are designed for enhancing communication and interaction between the social structures of society be applied within the walls of the enterprise?

Personally, I see this as having potential for a revolutionary change, rather than evolutionary change, in the way inter-company communication goes on and there’s a simple analogy to the world of SOA. Today, and even before the days of email, groupware, collaboration portals, etc., the primary model is still directed conversation. You’re either in the loop, or you’re not. To compare this to SOA, it’s a world where our focus is still on application A calling application B. What’s missing is support for undirected conversation. Combine SOA with EDA, and you have a much more powerful environment. The actions taken by application A and application B are events, and those events may be valuable to other applications. If those other applications have no visibility into those events, that value is left on the table. The same goes for our social interactions. If that information is kept private, there is value left on the table. You may counter, “It’s all out there in my SharePoint site,” but that doesn’t constitute an event-based system. While the information is there, it’s not conducive to searching, filtering, reading, etc. This is where an environment like Facebook has the potential to add much more than an email/IM/portal-based environment that is the norm today. The key is the news feed. It consists of messages from people (friends), but also from applications, coupled with more of the traditional collaboration tools of messaging, chat, file sharing, etc. While the Facebook news feed may not be quite as flexible as Twitter feeds, it’s clear that it’s headed in that direction. The key to success, however, is getting those events published. If applications don’t publish events, it’s hard to achieve the full potential of SOA and BPM. Add employees to that sentence, and it’s hard to achieve the full potential of the organization.

Unfortunately, asking a corporate enterprise to simply start using the public Facebook for these purposes is asking for too large of a leap. While I do think we will get to the point where the technology must allow the corporate communications to extend to parties outside the company, today, it’s still largely a private conversation. Requiring companies to fit their needs into the current consumer-driven, public environments is a big leap for old established companies. The right first step is an environment that packages up all the features of Facebook that are appropriate for a corporate environment and make that available initially as it’s own private world, but with a clear path to integration with the broader, public Facebook. This doesn’t mean that they’re installing it in their own data center, although that could be an option, it just means that it’s a walled garden for that company. It’s like the difference between Yammer and Twitter.

I’m looking forward to seeing more stories of companies leveraging social networking platforms inside their walls and then taking the next step of extending that to external communities as appropriate. I hope that we’ll see some case studies out of some large, established enterprises and not see adoption limited to the world of the new startups that begin with a culture built around these tools.