Todd Biske: Outside the Box

Archive for January, 2009

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.

I just happened to check my FeedBurner statistics and see that as of the first business day of 2009, I had over 1,000 subscribers to this blog for the first time. With a nice push of new subscribers from serverside.com due to Jack van Hoof’s review of my book that was posted there, I’m now over 1,100. While my posting frequency has slowed a bit, I hope to continue to provide useful information to all of you. As a corporate practitioner, I always enjoy hearing what peers are doing, so if there’s something you’d like me to talk about that may be relevant to your work, drop me an email or direct message on Twitter, and if it’s something I’ve thought about or worked on, I’ll do my best to share what I can. Again, thanks for your readership.

Here’s a topic for which I’d really like some community input, and I think it’s something that many of my readers have probably had to do, are doing, or would be interested in the result. If you’re adopting SOA, you’re likely using a Service Registry/Repository of one form or another. It can range from a set of scribbled notes on a whiteboard or post-its in some architect’s office/cube, to Excel, to one of the many vendor products available for this purpose. So, assuming you are actually using one of these mechanisms, what are you recording about your services, the consumers of those services, and how/where are you capturing the relationship between the two? In this post, I’m going to start with the first question, the answer to which constitutes what I call the technical service record. Please note that the focus of this is on services that have a programmatic interface, and not the broader business service or ITIL service space, although I am very interested in the overlap between this record and the service record that would existing in an ITIL v3 Service Portfolio.

Here’s a list of items that could be recorded about a service to get the discussion started. For each item, I’ve provided a description of what that item is, whether it is optional or not, the visibility of that item (public, consumers only, service manager only, etc…). Please contribute your thoughts on other attributes that could/should be captured along with its optionality (is that a word?) and visibility.

Of course, now that I attempted to put this list down with some simple attributes, I’ve realized that whether or not things are required or visible to particular parties are dependent on the status of the service, whether it is exposed externally or not, the interface type, etc. It’s just hard to make that fit into an HTML table and still have this entry be readable. Anyway, if there isn’t anything proprietary or confidential about the structure of your service records, consider sharing it here. I promise to publish the end result of this effort here for all to share for free. This isn’t limited to Web Services, either. If you’re using REST, what information would you provide about the collection of resources that comprise the service to potential users of those services? I would guess that many of the above attributes would still apply, and could certainly be accessed themselves through a REST interface, since a serivce record is a resource in and of itself.

Thanks for your participation! If you’d prefer to send me your information directly without publicly posting it here, send me an email at todd at biske dot com or you can send me a direct message on twitter at toddbiske.

In a RIA Weekly podcast, Michael Coté and Ryan Stewart had a brief conversation on the role of RIAs in portals. They didn’t go into much details on it, but it was enough to get me noodling on the subject.

In the past, I’ve commented on the role of widgets/gadgets ala Apple’s Dashboard and Vista’s Sidebar and how I felt there was some significant potential there. To date, I haven’t seen any “killer app” on the Mac side (I have no idea about Vista given that I don’t use it at home or at work). One thing that I found curious, however, was that when I went looking for a decent Twitter client for the Mac, there was no shortage of dashboard widgets, but actually very few desktop apps. I wound up choosing Twirl initially, and am now using TweetDeck. Both of these are Adobe AIR applications.

So what does this have to do with portals? Well, my own view is that your desktop is a portal. A portal should contain easy access to all of things you need to do to do your job. The problem with desktops today, however, is that the typical application is so bloated, that the startup/quit process is very unproductive, and if you leave them open all the time, you need dual monitors (or a really big monitor) and a boatload of memory (even though most isn’t getting used). For this reason, I still really like the idea of these small, single-purpose widgets that do one thing really well. The problem with it right now, however, is that Dashboard and Sidebar fall into the out-of-sight/out-of-mind category. I want my Twitter client in a visible portion of my desktop at all times, or at least with the ability to post a visual notification somewhere. If I leverage a Dashboard widget, it’s invisible to me unless I hit a function key. It’s out-of-band by intent. There are things that belong there. That being said, the organizational features of Dashboard could easily be applied to the desktop, as well. If I had a bunch of lightweight widgets that I used to do the bulk of my work always available on my desktop, that would be great. It had better perform better than the current set of applications that I have set to start at login, however.

Where does RIA fit in? I don’t know that I’d need portability from my desktop in a browser-based portal environment. I’m sure there a people out there that do everything they need to do on a daily basis via Firefox and a whole bunch of plugins. I’ve never tried it, nor do I have any interest in doing so, but for people in that camp, common technology between a desktop portal and a browser-based portal could be a good thing for them. For me, my primary interest is simply getting a set of lightweight tools for 80% of my day-to-day tasks that aren’t so bloated with stuff I don’t need. I thought a bit about portability of my desktop environment across machines (i.e. the same TweetDeck columns at work and at home), but I think that’s more dependent on these widgets storing data in the cloud than it is on storing the definition of my desktop in the cloud somewhere, but that might be of interest, as well.

The gist of all of this is that I do believe there are big opportunities out there to make our interaction with our information systems more efficient. Can RIAs play a role? Absolutely, but only if we focus on keeping them very lightweight, and very usable.

Brenda Michelson asked the blogosphere, “What does a ‘would & could attend’ IT conference look like?” In her post, she suggested some items that are ones that are required for establishing initial interest (i.e. things that make us say, “I would like to attend that), including credible speakers, compelling topics, peer interaction, immersive experience, participatory programs, etc. She then called out some constraints that come into play when answering whether or not we could attend. Those constraints include cost, proximity, dates, etc. The premise is that the finding the right intersection of attributes creates the “would & could attend.”

First, let me describe why I attend conferences. I don’t normally use conferences to learn about new areas. Instead, I go to conferences to extend my knowledge in an areas. Sometimes it may be an effort to go from “100-level” knowledge to “200-level” and sometimes it may be in areas where I know a lot, and I’m just hoping to find some nugget through sharing experiences. Given that, the conference sessions that interest me the most are almost always ones that involve a panel of practitioners. By practitioners, I mean corporate IT employees and not consultants, analysts, or vendors. This doesn’t mean that I don’t think that consultants, analysts, and vendors have anything good to contribute, it just means that their presentations have less potential value for me. While any speaker should view the effort as a marketing opportuntity, it obviously has more of an impact on the bottom line for consultants, analysts, and vendors. A practitioner must understand that their speaking does have an impact on recruiting efforts for their employer, however, it’s typically not a primary concern and unlikely that anyone is tracking the number of recruiting leads that came out of the speaking engagement. The practitioner is there to share best practices and hopefully engage in conversations with peers about their efforts in the same space. Unfortunately, these are frequently few and far between.

Other factors that come into play on the “would” portion are the agenda. I’ve never attended an “un-conference,” and I think this would be a bit more difficult to pull off in the EA space than it would be in the general development space. I’m not against the concept, but I think you need to have a very strong base of people committed to ensuring that conversations on interesting topics will happen. My experience with items in the middle, like birds-of-a-feather sessions are similar. Unless there’s someone in the discussion committed to keeping the conversation going, the sessions are duds. At the same time, there’s a risk that such a person becomes the sole presenter. A facilitator that ensures discussion, rather than presentation, happens is critical. I’d err on the side of having defined topics, pre-planned questions, but then structuring the sessions in a way to allow lots of time for interaction. Here, the moderator/facilitator is key. If the audience isn’t willing to participate, the facilitator must fill the time with relevant questions. This is a big risk, because for every 1 person I find that is willing to share experiences, there are probably 10 or 20 who are only interested in receiving, whether due to their own personality, level of knowledge, restrictive information sharing policies of their employer, or one of many other reasons.

The other challenge with all of this is that someone needs to pay for all of this. Practitioners don’t have a marketing budget to fund IT conferences like a vendor, consultant, or analyst firm might. As a result, I think you’re more likely to find these type of conversations through local user groups, however, the issue I have with those is that they always occur during evenings, time which I spend with my family. I’d rather be doing this during my work hours, as these conferences are work-related. Addditionally, unless you work in a very big city, there may not be enough participants to sustain the discussion. I live and work in the St. Louis metro area, and there are still many large organizations here that don’t have an EA practice, so sustaining something at a local level would be difficult. Therefore, I’m willing to sacrifice some portion of the conference time to allow vendor, analyst, or consultant presentations that would offset the costs to me. That being said, I’d like to see at least 50% of the sessions be from practitioners, and I’d be willing to give up frills (meals, conference schwag, evening entertainment, etc.) to keep that balance.

As for other factors, location, dates, costs, etc. all of them have been less of a decision factor for me. Obviously, in today’s economy, the cheaper the better, and it’s always nice when I can consider bringing my family with me and let them be entertained by the area while I go learn things, but it usually all comes down to whether or not I’m going to learn something and have some facilitated interaction with my peers. By the way, I also think that so-called “networking sessions” where they group people at a meal according to their industry vertical or some other attribute don’t cut it. While, you may have a good conversation about the weather at the conference site or current events, and may meet some nice people, they’re unlikely to result in information sharing relevant to the conference topic unless someone steps in as a facilitator.

Note: I just read James McGovern’s response to Brenda’s post, and I like his idea of a “Hot Seat” question. I would have no problem being asked questions without knowing the questions in advance, with the appropriate restrictions on discussing intellectual property and keeping questions on the topic at hand.

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.

A break from the enterprise IT posts with this one. Since I did quite a bit of googling on it prior to Christmas without great results, I wanted to make sure I posted an entry about my new car stereo, the Pioneer DEH-P4000UB. It comes with a USB port (accessible via a cable that’s threaded into your glove compartment), and is iPod-compatible. Even better, it’s also iPhone 3G compatible, although your iPhone will initially report that the connected device may not supported and will ask you if you want to go into airplane mode. Answer no. From there, you can now play and charge your iPhone 3G through the car stereo with far better quality than an FM transmitter or a cassette adapter. You can control playback either through the stereo controls, the remote control for the car stereo, or the iPhone. I’ve been very, very pleased with the unit. My only complaint is that the “universal controller” knob on the stereo is very non-intuitive, so you’ll need to read the owner’s manual to figure out how to preset radio stations, etc. I found the iPod/iPhone integration to be easier to navigate when using the remote control than using the universal controller, but I tend to just use the iPhone’s controls to choose a podcast.

So, if you’re out there looking for a new head unit for your car and want to be able to charge your iPhone from it, and playback your music or podcasts, take a look at the Pioneer DEH-P4000UB. There’s a video review on Crutchfield, and you can buy it at Best Buy or Amazon.com. This head unit does not include bluetooth capabilities, but I’m pretty sure that Pioneer sells a bluetooth add-on for it. I can’t comment on that, since I didn’t get it. Hopefully, however, this review will help others that are looking for a car stereo that will work natively with the iPhone 3G as I was.

Some recent conversations about the use of workflow and orchestration technologies got me thinking about how to properly look for value when trying to apply these technologies, whether associated with a BPM suite, or with any of the other multitude of tools out there that claim to have orchestration/automation/workflow/work management capabilities.

The one common term that always comes up is process. All of these tools always wind up having some sort of process definition be a requirement. There is one big factor, however, that has a significant impact on where you should look for value, and that’s whether those processes involve manual (i.e. done by a person) activities or not.

Let’s handle the simpler of the two cases, first, which is where there is no manual activities whatsoever. In this case, what we’re really talking about is process automation. If there are no manual steps, then there is no reason that the entire process can’t be fully automated. If we fully automate a process, what are the factors in the value equation? Clearly, if the process isn’t fully automated today, there is a one-time benefit in efficiency. The execution time should move from a variable, potentially unpredictable value, to a consistent, predictable value. This is the case regardless of what tools we use to automate it. Theoretically, I could automate the process with scripts or a programming language and achieve the same value. If you agree with me, then the real value contribution in applying BPM/Workflow technologies lies not in the run-time space, but in the development time space. By either reducing inefficiencies in the communication between analysts and developers through a common language (a process model), or by improving productivity in the development time through the drag-and-drop visual environments of most tools, value can be obtained through time-to-delivery. Beyond this, there is probably not as much value to be obtained through the “management” portion of the BPM suite. Even if the process is subject to frequent change, the area of interest is the time to deliver the change, not optimization of the process itself, since by fully automating the process, we should assume it’s also fully optimized.

If we throw manual tasks into the equation, then we have a different story. While the development time efficiencies certainly still apply, there’s now significant value that can be obtained through process analysis and optimization. I need to know how long those manual tasks take, why Judy accomplishes more tasks than John, what chaos ensues when Fred calls in sick, what the impact of task assignment and escalations are, etc. This information can be obtained by managing the processes, through instrumentation, analytics, and reporting. By doing so, we can get into a cycle of continuous improvement, and strive to optimize the manual efforts that can’t be automated.

Now the reason I bring this up is that there are no shortage of tools that claim to have workflow/business process capabilities. If you have a BPM suite, now you’re faced with the question of which workflow tool to use. What you need to think deeply about is where you’re going to get your value. Products with workflow capabilities may have advantages in development time value because they will come pre-populated with actions/tasks appropriate to the context of that tool, while a generalized BPM platform may not. The flipside, however, is that those same tools with workflow capabilities may only provide a piece of the BPM suite, namely, business process development. If what you really need is business process management, with the ability to monitor, analyze, and optimize the manual parts of your processes, then you may need to sacrifice some development time efficiencies to get the more important run-time value.

Finally, keep in mind that not all work can be defined by a process. As Keith Harrison-Broninski talks about in his book, Human Interactions: The Heart And Soul Of Business Process Management: How People Reallly Work And How They Can Be Helped To Work Better, there will always be ad hoc work. You’ll still need to consider how to best utilize technology to support those ad hoc activities, rather than trying to define a rigid process for something that isn’t.