Todd Biske: Outside the Box

Archive for the ‘Governance’ Category

In a two-part podcast series, Dave Berry from Oracle’s Fusion Middleware team and Mike van Alst, a consultant with IT-eye, discussed some remarks I made in an earlier OTN Arch2Arch podcast regarding SOA and reuse. Specifically, I tried to de-emphasize the reuse aspect of SOA. Many reuse programs that I’ve seen or read about have two key elements:

1. Building things in a reusable manner
2. Making those things visible

While noble goals, these approaches are at significant risk of producing the intended results. The first item has a fundamental problem in that it is all but impossible to define exact what “building in a reusable manner” is. We can use open, interoperable standards rather than closed, proprietary ones, but is this the key barrier to reuse? There’s probably some low hanging fruit that this will capture, but there’s so much more to reuse than this. From a technical standpoint, one must also consider the structures of the information being exchanged and the varying granularity of the information being exchanged, among other things.

On the second item, visibility is important, there’s no doubt about it. But visibility without context will not be successful. It’s a matter of providing the right information at the right time. Too many initiatives that are associated with the collection of IT artifacts, be it reuse, SOA, portfolio management, ITSM, or any of the like, fail because the information is never put into the context of the processes that need that information. How many times have you seen the information collected as part of a fire drill for an immediate need, only to grow stale once that fire drill is completed.

The two things I recommend are service ownership and linkage to key IT processes. If you’ve heard me talk on panel discussions at conferences, you’ll know that my answer to the question, “What’s the one piece of advice you have for companies adopting SOA?” has always been, “Define your service owners.” Someone is given the responsibility for a functional area, providing capabilities to the rest of the organization and accountable for driving out the redundancies that may exist. This is a tricky exercise, because service ownership has a cost associated with it. Expending that cost for a service that is only used by one consumer can lead to waste, so it’s not a silver bullet. It does, however, being the cultural change from a project-driven organization to more of a product-driven/service-driven organization. Without having someone accountable for the elimination of redundancy in a domain and serving the needs of consumers, it won’t happen.

The second piece of advice is the process integration. To avoid creating repositories that see infrequent use after initial population, you have to define the role of that information in the IT processes. If you have a service repository, when do you expect project architects and designers to look into that repository for services that may be appropriate. How about it the strategic planning process? The scoping effort for a project likely begins long before a project architect is assigned? How is the service repository used in those activities? By defining the links with key IT processes and ensuring that those processes are changed to use the repositories involved, with appropriate governance to make sure those changes are occurring, you will make sure that your services are visible, and more importantly, that the right people are looking for them at the right time.

Thanks to Google alerts, I found out that my book, SOA Governance, is now available via Safari Books Online. You can access it here. If you enjoy it, consider voting for me as the Packt Author of the Year.

While working on a maturity model, a colleague pointed out a potential pitfall to me. The way I had defined the levels, they were too focused on standardized processes, which was not my intent. Indeed, many maturity efforts, such as CMMi, tend to be all about establishing standard processes across the enterprise. The problem with this is that just because you have standard processes doesn’t mean you’re actually getting the intended results from the capability. I’m sure this will ring true with my friend James McGovern who has frequently lambasted CMMi in his blog. So, to fix things, I propose the following maturity levels, and I’d like feedback from my readers.

0. Not existent/Not applicable: The capability either does not exist at the organization, or is not needed.
1. Ad hoc: The capability exists at the organization, however, the organization has no idea whether there is consistency in the way it is performed, whether within a team or across teams, there is no way to measure the costs and benefits associated with it, and there are no target costs and benefits associated with it.
2. Measurable: The capability exists at the organization, and the organization is tracking the costs and benefits associated with it. There is no consistency in how the capability is performed either within teams or across teams, as shown by the measurements. The organization does not have any target costs and benefits associated with it.
3. Defined: The capability exists at the organization, the organization is tracking the costs and benefits associated with it, and the organization has defined target costs and benefits associated with the capability. There is inconsistency, however, in achieving those costs and benefits. Note that different teams can have different target costs and benefits, if the organization believes that a single, enterprise standard is not in its best interest.
4. Managed: The capability exists at the organization, the organization is tracking the costs and benefits associated with it, target costs and benefits have been defined, and the teams executing the capability are all achieving those target costs and benefits.
5. Optimizing: The capability is fully managed and processes exist to continually monitor both the performance of the teams performing the capability as well as the target costs and benefits and make changes as needed, whether it is new targets, new operational models (e.g. switching from a centralized approach to a decentralized approach, relying on a service provider, etc.), new processes, or any other change for the better.

Maturity levels need to show continual improvement, and it can’t be solely about standardizing a process, since it may not need to be standardized across the enterprise, nor may those processes actually achieve the desired cost levels, even though they are standardized. Standardization is one way of getting there, and I’ve tried to make these descriptors be applicable for many paths of getting there. Let me know what you think.

The publisher of my book, Packt Publishing, has announced a competition for Author of the Year. You can find out more about the award here, as well as cast your vote. I’ll be perfectly transparent and state that there is a cash award associated with this, although I’d be posting this even if there wasn’t. I’m proud of the book that I wrote and if others have received value from it, that makes me even happier. If you feel so inclined to recommend me to my publisher, I’d be honored, but know that I’m already honored by the fact that you’ve either read or just considered reading my book. Packt is also giving away some prizes to random voters, so there may be something in it for you, too. Thanks for your consideration, and hopefully, your vote!

I had a brief conversation with Nick Gall (Twitter: ironick) of Gartner on Twitter regarding designing for change. Back in the early days of SOA, I’m pretty sure that I first heard the phrase, “we need to build things to change” from a Gartner analyst, although I don’t recall which one. Since that time, there’s been a lot of discussion on the subject of designing/building for change, usually tied to a discussion on REST versus WS-*. Yesterday, I stepped back from the debate and thought, “Can we ever design for change, and is that really the right problem?”

As I told Nick, technology and design choices can certain constrain the flexibility that you have. Think about the office building that many of us work in. There was a time when they weren’t big farms of cubicle and they actually had real walls and doors. Did this design work? Yes. Was it flexible enough to meet the needs of an expanding work force? No. I couldn’t easily and quickly create new conference rooms, change the size of spaces, etc. Did it meet all possible changes the company would go through? No. Did the planners ever think that every cubicle would consume the amount of electricity they do today? What about wiring for the Internet? Sometimes those buildings need to be renovated or even bulldozed. The same thing is true on the technology side. We made some design decisions that worked and were flexibility, yet not flexible enough for the change that could not have been easily predicted in most companies, such as the advent of the internet.

Maybe I’m getting wiser as I go through more of these technology changes, but for me, the fundamental problem is not the technology selection. Yes, poor design and technology selection can be limiting, but I think the bigger problem is that we have poor processes for determining what changes are definitely coming, what changes might be coming, and how and when to incorporate those changes into what IT does, despite the available predictions from the various analysts. Instead, we have a reactive, project-driven approach without any sort of portfolio planning and management expertise. To this, I’m reminded of a thought I had while sitting in a Gartner talk on application and project portfolio management a year or two ago. If I’m sitting in a similar session on service portfolio management 5 years from now, we’ve missed the boat and we still don’t get it. Develop a process for change, and it well help you make good, timely design choices. The process for change involves sound portfolio management and rationalization processes.

Fellow Twitterer Leo de Sousa posted a review of my book, SOA Governance, on his blog. Leo is an Enterprise Architect at the British Columbia Institute of Technology, and is leveraging the book on their journey in adopting SOA. Thanks for the review, Leo. I’m glad you posted it before the Stanley Cup playoffs begin as my St. Louis Blues will be taking on your Vancouver Canucks, and I wouldn’t have wanted the upcoming Blues victory to taint your review!

I recorded a podcast on various SOA Governance topics with Bob Rhubart, Cathy Lippert, and Sharon Fay of Oracle as part of Oracle’s Arch2Arch Podcast series. You can listen to part one via this link, or you can find it at Oracle’s ArchBeat site here.

On Friday, the SOA Chief (Tim Vibbert), Brenda Michelson, and I had a conversation on Twitter regarding SOA governance and anonymous service consumers. Specifically, how do you provide run-time governance for a service that is accessed anonymously?

If you’ve read this blog or my book, you’ll know that my take on run-time SOA governance is the enforcement and/or monitoring of compliance with the policies contained within the service contract. Therein lies the biggest problem: if the service consumer is anonymous, is there a contract? There’s certainly the functional interface, which is part of the contract, but there isn’t any agreement on the allowed request rates, hours of usage, etc. So what do we do?

The first thing to recognize is that while there may not be a formal contract that all consumers have agreed to, there should always be an implied contract. When two parties come to the table to establish an agreement, it’s likely that both sides comes with a contract proposal, and the final contract is a negotiation between the two. The same thing must be considered here. If someone starts using a service, they have some implicit level of service that they expect to receive. Likewise, the service provider knows both the capacity they currently can handle as well as what how they think a typical consumer will use the service. Unfortunately, these implied contracts can frequently be wrong. The advice here is that even if you are trying to lower the barrier for entry by having anonymous access, you still need to think about service contracts and design to meet some base level of availability.

The second thing to do, which may seem obvious, is to avoid anonymous access in the first place. It’s very hard to enforce anything when you don’t know where it’s coming from. Your authorization policy can simply be that you must be an authenticated user to use the service. Even in an internal setting, having some form of identity on the message, even if there are no authentication or authorization policies, becomes critical when you’re trying to understand how the systems are interacting, perform capacity planning, and especially in a troubleshooting scenario. Even services with low barriers to entry, like the Twitter API, often require identity.

The next thing you should do is leverage a platform with elasticity. That is, the available capacity should grow and shrink with the demand. If it’s anonymous, and new consumers can start using it simply by getting the URLs from someone else, you have no control over the rate at which usage will scale. If the implied level of availability is that the service is always available, you’ll need on-demand resources.

Finally, you still need to protect your systems. No request is completely anonymous, and there are things you can do to ensure the availability of your service against rogue consumers. Requests will have source IP addresses on them, so you can look for bad behavior at that level. You can still do schema validation, look for SQL injection, etc. In other words, you still need to do DoS protection. You also should be looking at the usage metrics on a frequent basis to understand the demand curve, and making decisions accordingly.

I’m happy to announce I’ve now published a RefCard (reference card) on SOA Governance based on the content in my book from Packt Publishing. If you want to get a taste of what the book has to offer, follow this link over to DZone.com to download it for free.

I’ve refrained from incorporating the current economic crisis into my posts… until now. In a recent discussion, I compared the current situation to what many, many people do every new year. They make a resolution to lose weight, go on some fad diet or start going to the fitness center, maybe lose that weight, but then go right back to how their behavior was a few months prior and gain that weight (and potentially more) right back.

Enterprises are in a similar state. Priorities have shifted to where cost containment and cutting are at the top of the list. While the knee-jerk reaction is to stop investing in any long-term initiatives, this could be a risky approach. If I don’t eat for 4 days, I may quickly drop the weight I need to, but guess what? I still need to eat. Not eating for 4 days will only make me more unhealthy, and then when I do eat, the weight will come right back.

These times should not mean that organization drop their efforts to adopt SOA, ITIL/ITSM, or any other long-term initiative. Most of these efforts try to achieve ROI through cost reduction by eliminating redundancy in the enterprise, which is exactly what is needed today! The risk, however, is that these efforts must be held accountable for the goals they claim to achieve. They must also be prepared to adjust their actions to speed up the pace, if it is possible. No one could have predicted the staggering losses we’re seeing, and sometimes it is necessary for a company’s survival to adjust the pace. If these efforts are succeeding in reducing costs, however, we shouldn’t kill them just because they take a longer time to achieve their goals, otherwise we’ll find ourselves back in the same boat when the next change in priorities or goals happen.

The whole point of Enterprise Architecture, SOA, and many of these other strategic IT initiatives is to allow IT to be more agile- to respond more quickly to changes in the business objectives. Guess what? We’re in the middle of a big unprecedented change in our lifetime. My guess is that the best survivors of this meltdown will be organizations that don’t go on a starvation diet, but instead simply recognize that their priorities and goals have changed and execute without significant disruption to the way they utilize IT. If your EA team, SOA efforts, ITIL efforts, or anything else are inefficient and not providing the intended value, then you’re at risk of being cut, but you were probably at risk anyway, now someone just happens to be looking for targets. If EA has been adding value all along, then you’ll probably be a strategic asset that will help your organization weather the storm.

According to Google Analytics, here are the top read posts from my blog for 2008. This obviously doesn’t account for people who read exclusively through the RSS feed, but it’s interesting to know what posts people have stumbled upon via Google search, etc.

10. Governance Does Not Imply Command and Control. This was posted in August of 2008, and intended to change the negative opinion many people have about the term “governance.”

9. To ESB or not to ESB. This was posted in July of 2007, and gave a listing of five different types of ESBs that exist today and how they may (or may not) fit into your environment.

8. Getting Started with SOA Governance. This was posted in September of 2008, just before my book was released. It emphasizes a policy first approach, stressing education over enforcement.

7. Dish DVR Upgrade. This was posted in November of 2007 and had little to do with SOA. It tells the story of how Dish Network pushed out an upgrade to the software on their DVRs that wiped out all of my existing timers, and I missed recording some shows as a result. The lesson for IT: even if you think there’s no chance that a change will impact someone, you still should make them aware that a change is occurring.

6. Most popular posts to date. This is rather humorous. This post from July of 2007 was much like this one. A list of posts that Google Analytics had shown as most viewed since January of 2006. Maybe this one will show up next year. It at least means someone enjoys these summary posts.

5. Dilbert’s Guide to Governance. In this post from June of 2007, I offered some commentary on governance in the context of a Dilbert cartoon that was published around the same timeframe.

4. Service Taxonomy. Based upon an analysis of search keywords people use that result in them visiting my pages, I’m not surprised to see this one here. This was posted in December of 2006, and while it doesn’t provide a taxonomy, it provides two reasons for having taxonomies: determining service ownership and choosing the technical implementation platform. I don’t think you should have taxonomies just to have taxonomies. If the classification isn’t serving a purpose, it’s just clutter.

3. Horizontal and Vertical Thinking. This was posted in May of 2007 and is still one of my favorite posts. I think it really captures the change in thinking that is required for more strategic solutions, however, I also now realize that the challenge is in determining when horizontal thinking is needed and when it is not. It’s not an easy question and requires a broad understanding of the business to answer correctly.

2. SOA Governance Book. This was posted in September of 2008 and is when I announced that I had been working on a book. Originally, this had a link to the pre-order page from the publisher, later updated to include direct links there and to the page on Amazon. You can also get it from Amazon UK, Barnes and Noble, and other online bookstores.

1. ITIL and SOA. Seeing this post come in at number one was a surprise to me. I’m glad to see it up there, however, as it is something I’m currently involved with, and also an area in need of better information. There are so many parallels between these two efforts, and it’s important to eliminate the barriers between the developer/architecture world of SOA and the infrastructure/operations world of ITIL/ITSM. Look for more posts on this subject in 2009.

Jack van Hoof posted a review of my SOA Governance book on his SOA and EDA blog. In it, he states:

Reading this book felt like taking a hot shower. As professional architects, we all understand what Todd has written (or don’t we?). But owning one handy book of hardly 200 pages with all those thoughts structured and combined at an appropriate level of understanding feels like possessing a jewel.

Thanks for the review, Jack. You can read his full review here.

In response to my post on the “Effective Governance” talk given at the Gartner EA Summit, Ron Rosenhead said:

For me there are a couple of overlapping issues:
Do project boards actually know what they are established for? Plus, how well trained are members of project boards? I have to say that my experience here in the UK is that Boards are established sometimes with (overly) large numbers, give little guidance and are not well trained in understanding what they are to do and in project management. They usually receive the thumbs down from project managers who say they add little or no value.
Yes, they should set the parameters of decision making and enable others to make decisions. If I was to ask everyone who came through courses we ran in 2008 very few would say that this had actually happened.

His first question is really a great point. All too often, these boards are created without sufficient direction to be effective. If I were on one of these boards, even though it might be boring, I’d really want to just be able to rubber stamp as many of the projects as possible. That can only happen if the board effectively sets expectations in advance so the project teams know what they’re in for. If the project team is forced to guess as to what the board will want, it’s far more likely that they’ll guess incorrectly. At the same time, if the expectations are set, it’s also important for the review board to move through it as quickly as possible. If the team has done their homework, provided the information necessary, don’t waste the project team’s time by walking through the answers for an hour knowing full well that they’ve complied with the policies. This is why I like having explicit policies and think that the use of self asssessments via scorecards can be a very powerful tool.

Another review of my book has been posted here at the Exforsys, Inc. (Execution for System) site. I’m not familiar with Exforsys, but they seem to be an aggregator/news provider of IT training resources and news. Anyway, the author of the review gave a very thorough review of the book, so if you’re on the fence of whether or not my book is a good resource for your SOA Governance efforts, this review may aid you in your decision making process.

Presenter: Scott Bittler, Gartner

Another presentation from Scott, this time over breakfast. The bulk of this talk was focused on the importance of what he termed as “Next State Architecture.” If we have the future state and current state architectures documented, the challenge that exists is if we can’t achieve the future state architecture in one step. If that’s the case, then there’s a gap in the prescriptive guidance needed for project teams. If they know they can’t get to the future state, and don’t have guidance on how they should move from current state, they’re likely to stick with what they know. Good advice.

There were some specific nuggets outside of this core topic that I also wanted to call out. First, he said that the most important EA deliverable is principles, because it’s those principles that lead to consistent decision making. The talk wasn’t focused on this, so he didn’t go into depth, but some examples of these principles would be good. I definitely see the importance in these and agree with his statement. I’ve been in many situations with two (or more) compelling options where we seem to be at a stalemate. The principles need to assist in getting decisions made.

Second, I liked the fact that he said that EA’s role is to provide prescriptive guidance so that appropriate choices are made on projects and programs. This emphasizes the point that I was hoping would be made in his governance talk yesterday. Provide the policies, and anyone can make the right decisions.

Finally, the last comment he made was that with the advent of EA-focused web sites, etc., any team that claims ignorance when confronted with non-compliance (“I didn’t know I was supposed to do that”) is unacceptable in this day. Here, I disagree. I make extensive use of RSS feeds in my work so that I get information pushed to me, but I know many of my colleagues do not. A web site is still a pull-model, and there’s very few people that I know of that have the discipline to regularly check common web sites. EA has to be accountable for the communication effort and ensuring that it gets pushed out to the people who need it. Putting it on a web site isn’t enough. So, this one I disagree with. I think if EA is serious about achieving compliance, then they should be serious about pushing the information out. Create a formal communication plan and execute it.