Todd Biske: Outside the Box

Archive for January, 2010

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

I participated on a panel discussion on communication and enterprise architecture, hosted by Bob Rhubart of Oracle. Part one is now posted on Oracle’s Technology Network, with parts 2 and 3 to follow soon.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

I couldn’t resist sharing my thoughts about the iPad along with every other technology pundit out there. I’m very intrigued by the possibilities of the iPad. From what was announced on stage, there’s nothing that immediately jumps out to say, “Wow, this is going to change world.” The reason for this, however, is because that ship already set sail with the iPhone/iPod touch. I recently read an article about Apple’s approach to user interface technology, and how the touchscreen display was really the game changer. Why be burdened by a full keyboard if you don’t need it? Instead, allow the interface to be fully customizable to the task at hand. The iPhone/iPod touch did this. The iPad is a recognition that the small form factor of the iPhone is simply not suitable for all applications. If the handheld form factor is class one, then something around the size of a sheet of paper is form factor two. Anything bigger than that starts to make more sense in a desktop setting, rather than being primarily portable.

Given this angle, I think the iPad positioning makes a lot of sense. Frankly, it’s surprising we haven’t reached this point sooner. Way back in the early nineties, I took a seminar course in graduate school on human computer interaction, and four or five students had to engage in panel discussion on where interfaces would go five or ten years from then. I don’t think a single one of them expected the keyboard and mouse to still be the dominant UI technology almost twenty years later, but that is the case. It’s time to recognize that while well suited for some activities, that interface is also a boat anchor for other activities. A platform like the iPad now opens things up to more customized interfaces that may be much more efficient and intuitive for tasks. Ironically, I think it’s this same thinking that pushed Apple away from the original web-based focus of the original iPhone and into the world of custom apps. While a developer may be able to reach a wider audience with a browser based application, that’s at the sacrifice of the UI, despite AJAX, Flash, HTML 5. This is also why I don’t see Flash support as a big deal. Yes, it prevents us from watching browser based video, but I’d much rather have a specialized app with a more intuitive interface for doing so. Why be burdened by the web browser if you don’t have to?

So, is the iPad revolutionary? No, I think it’s evolutionary from the iPhone/iPod touch. I’m very interested to see what applications can be developed for this form factor for the educational and medical markets. On a laptop, it’s likely that those advanced applications would have required a desk, because there’s just no way to hold the laptop, with it’s keyboard, and try to manipulate the track pad, pointer nub (whatever it’s called), or a mouse to achieve the interaction needed. With the iPad, it’s cradled in one arm, with your other hand free. You can have advanced interactions. This is where it will show its stuff. Just as the iPhone didn’t have too much to show with v1, but the partner apps became much more sophisticated with the 3G and the 3GS, the same will be true with the iPad. Two to three weeks didn’t allow partners to show much at the kickoff, but I think we’ll all look back a year from now and see some revolutionary apps that have been freed from the burden of the keyboard and mouse interface.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

David Linthicum continued the conversation around design-time governance in cloud computing over at his InfoWorld blog. In it, he quoted my previous post, even though he chose to continue to use the design-time moniker. At least he quoted the paragraph where I state that I don’t like that term. He went on to state that I was “arguing for the notion of policy design,” which was certainly part of what I had to say, but definitely not the whole message. Finally, Dave made this statement:

The core issue that I have is with the real value of the technology, which just does not seem to be there. The fact is, you don’t need design-time service governance technology to define and define service policies.

Let’s first discuss the policy design comment. Dave is correct that I’m an advocate for policy-based service interactions. A service contract should be a collection of policies, most if not all of which will be focused on run-time interactions and can be enforced by run-time infrastructure. Taking a step backward, though, policy design is really a misnomer. I don’t think anyone really “designs” policies, they define them. Furthermore, the bulk of the definition that is required is probably just tweaking of the parameters in a template.

Now, moving to Dave’s second comment, he made it very clear that he was talking about governance technology, not the actual governance processes. Speaking from a technology perspective, I’ll agree that for policy management, which includes policy definition, all of the work is done through the management console of the run-time enforcement infrastructure. There are challenges with separation of concerns, since many tools are designed with a single administration team in mind (e.g. can your security people adjust security policies across services while your operations staff adjust resources consumption while your development team handles versioning, all without having the ability to step on each other’s toes or do things they’re not allowed to do?). Despite this, however, the tooling is very adequate for the vast majority (certainly better than 80-90% in my opinion) of enterprise use cases.

The final comment from me on this subject, however, gets back to my original post. Your SOA governance effort involves more than policy management and run-time interactions. Outside of run-time, the governance efforts has the closest ties to portfolio management efforts. How are you making your decisions on what to build and what to buy, whether provided as SaaS or in house? Certainly there is still a play for technology that support these efforts. The challenge, however, is that processes that support portfolio management activities vary widely from organization, so beyond a repository with a 80% complete schema for the service domain, there’s a lot of risk in trying to create tools to support it and be successful. How many companies actually practice systemic portfolio management versus “fire-drill” portfolio management, where a “portfolio” is produced on a once-a-year (or some other interval) basis in response to some event, and then ignored for the rest of the time, only to be rebuilt when the next drill occurs. Until these processes are more systemic, governance tools are going to continue to be add-ons to other more mature suites. SOA technologies tried to tie things to the run-time world. EA tools, on the other hand, are certainly moving beyond EA, and into the world of “ERP for IT” for lack of a better term. These tools won’t take over all corporate IT departments in the next 5 years, but I do think we’ll see increased utilization as IT continues its trend toward being a strategic advisor and manager of IT assets, and away from being the “sole provider.”

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

David Linthicum started a debate when he posted a blog with the attention grabbing headline of “Cloud computing will kill these 3 technologies.” One of the technologies listed was “design-time service governance.” This led to a response from K. Scott Morrison, CTO and Chief Architect at Layer 7, as well as a forum debate over at eBizQ. I added my own comments both to Scott’s post, as well the eBizQ forum, and thought I’d post my thoughts here.

First, there’s no doubt that the run-time governance space is important to cloud computing. Clearly, a service provider needs to have some form of gateway (logical or physical) that requests are channeled through to provide centralized capabilities like security, billing, metering, traffic shaping, etc. I’d also advocate that it makes sense for a service consumer to have an outgoing gateway, as well. If you are leveraging multiple external service providers, centralizing functions such as digital signatures, identity management, transformations, etc. makes a lot of sense. On top of that, there is no standard way of metering and billing usage yet, so having your own gateway where you can record your own view of service utilization and make sure that it’s line with the what the provider is seeing is a good thing.

The real problem with Dave’s statement is the notion that design-time governance is only concerned with service design and development. That’s simply not true. In my book, I deliberately avoided this term, and instead opted for three timeframes of governance: pre-project, project, and run-time. There’s a lot more that goes on before run-time than design, and these activities still need to be governed. It is true that if you’re leveraging an external provider, you don’t have any need to govern the development practices. You do, however, still need to govern:

• The processes that led to the decision of what provider to use.
• The processes that define the service contract between you and the provider, both the functional interface and the non-functional aspects.
• The processes executed when you add additional consumers at your organization of externally provided services.

For example, how is the company deciding what service provider to use? How is the company making sure decisions by multiple groups for similar capabilities are in line with company principles? How is the company making sure that interoperability and security needs are properly addressed, rather than being left at the whim of what the provider dictates? What happens when a second consumer starts using the service, yet the bills were being sent to the first consumer? Does the providers service model align with the company’s desired service model? Does the provider’s functional interface create undue transformation and integration work for the company? These are all governance issues that do not go away when you switch to IaaS, SaaS, or PaaS. You will need to ensure that your teams are aware of the contracts in place, and don’t start sending service requests without being properly onboarded into the contractual relationship. Your internal allocation of charges takes multiple consumers into account, if necessary. All of these must happen before the first requests are sent in production, so the notion that run-time governance is the only governance concern in a cloud computing scenario is simply not true.

A final point I’m adding on after some conversation with Lori MacVittie of F5 on Twitter. Let’s not forget that someone still needs to build and provide these services. If you’re a service provider, clearly, you still have technical, design-time governance needs in addition to everything else discussed earlier.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

Sometimes a simple message can be the most powerful. In a recent discussion on a SOA Consortium phone call, I made the comment that IT needs to shift its mentality from provider to advisor. I hope that most people read this and view it as completely obvious, but recognizing the fact and actually executing against it are two different stories.

Let’s look at two trends that I think are pretty hard to argue against in most corporate IT organizations. The first trend is to build less stuff. Building less means that we’re either reusing stuff we already have, or acquiring stuff from some other source and configuring (not customizing) it to meet our needs. This could be free stuff, COTS, SaaS, etc. The point is, there is no software development required.

The second trend can be summed up as buy fewer (none) servers. Virtualization, data center consolidation/elimination, and cloud computing all have ties back to this trend, but the end result is that no one wants to build new data centers unless data centers are your business.

So, if you accept these trends as real, this means that IT isn’t providing applications and IT isn’t providing infrastructure. Then what is IT providing? I would argue that rather than looking for something new to “provide,” IT needs to change its fundamental thinking from provider to advisor or be at risk of becoming irrelevant.

Am I simply stating the obvious? Well, to some extent, I hope so. What should also be obvious, however, is that this change in role at an organizational level won’t happen by accident. While an individual may be able to do this, redefining an entire organization around the concept is a different story. A provider typically needs to only understand their side of the equation, that is, what they’re providing. If you’re a software developer, you understand software development, and you sit back and wait for someone to give you a software development task. Often times, the provider may establish some set offerings, and it’s up to the consumer to decide if those offerings meet their needs or not. An advisor, on the other hand, must understand both sides of the problem: the needs of the consumer and the offerings of the provider.

To illustrate this, take an example from the world of financial services. A broker may simply be someone you call up and say, “Buy 100 shares of APPL at no more than $200.” They are a provider of stock transaction services. A financial advisor on the other hand, should be asking about what your needs are, and matching those against the various financial offerings they have at their disposal. If they don’t understand client needs or if they don’t understand the financial offerings, you’re at risk of getting something sub-optimal.

IT needs to shift from being the technology provider to the technology advisor. Will people outside of IT continue to hand-pick technology solutions without the right breadth of knowledge? Sure, just as people today go out and buy some stock without proper thought of whether that’s really the right investment for them or just what everyone else is doing. The value add that IT needs to offer is the same that financial consultants do. We provide significantly better depth of understanding of the technology domains, along with the right amount of understanding of the business domains of our companies to advise the organization on technology decisions. For the non-IT worker that loves technology, it should be seen as validation of their efforts (not a roadblock).

The final message on all of this, however, is that I believe architecture plays a critical role. To actually build an advisory organization, you must categorize both the technology and the business into manageable domains where people can build expertise. Where does this categorization come from? Architecture. Taking a project-first approach is backwards. Projects should not define the categories and the architecture, the categories and desired architecture should define the projects.

So, you can see that this simple concept really does represent a fundamental shift in the way of thinking that needs to occur, and it’s one that’s not going to happen overnight. If you’re a CIO, it’s time to get this message out and start defining the steps you need to take to move your organization from a provider to an advisor.