Todd Biske: Outside the Box

Archive for August, 2009

A Gartner press release resulted in some very good posts in the blogosphere related to the future of enterprise architecture. Gartner coined the term ’emergent architecture’ and encouraged companies to adopt it. For the record, I’ve decided that I really don’t like that term, and I don’t think Gartner did a very good job of defining it. They provided a list of seven differentiators from “the traditional approach to EA” but, as Mike Rollings of Burton Group pointed out in his post, most of these things are items that many practicing enterprise architects already did and knew. Do we really need a term for what many of us are already doing?

The post that I really liked came from Dion Hinchliffe at ZDNet. The reason for this is the image that he used in the post, shown here:

While I still don’t like the use of the term emergent architecture and “non-deterministic outcomes”, the picture tries to draw a picture of the forces the come into play in producing solutions.

So what is the role of EA in the future? First, the thing that doesn’t change is the role of EA in providing context. This context is an influencer on the activities that occur in the enterprise. Dion’s drawing attempts to touch on this, but goes at the scope of influence in terms of who can be influenced, rather than the information used to influence. It’s the role of the enterprise architect to bring additional context from outside of the normal scope of the effort to the solution discussion. Influence is not about centralized decision making, so as Mike Rollings called out, most EA’s have never been a centralized decision maker for all things architecture and never will be. We’re simply another party providing influence. Sometimes we have stronger methods, sometimes someone else does. In my book, SOA Governance, I emphasized policy creation first, then policy communication. If the policies are known, any decision maker can apply those policies consistently.

What Dion’s diagram doesn’t capture, is the changing way in which solutions get done. He still has the “projects” box up there. There are many of us that feel this project-based culture is part of the problem. If we take a more product-based or even service-based view of our solutions, those solutions will need to be nurtured and evolve over time, rather than stood up, ignored, and then uprooted with significant effort. This notion, as others have called out, including Neil Macehiter and Neil Ward-Dutton in their book The Technology Garden and practicing enterprise architect James McGovern in his blog, is that of gardening. Do you simply let anything emerge in your garden? No. You plant specific things, remove the weeds, remove weak plants, change some things from year to year, etc. If you don’t plan the garden properly, weeds can choke the life out of other plants, or there can be conflicts within the garden itself, with one type of plant consuming higher amounts of resources, causing others to wither and die.

Coming back to the role of EA as influencer though, the thing we must realize is that the dynamics around us are changing, and as a result, it may change who and how we influence. More and more things are bought rather than built. The level of consumer technology has changed the bar in terms of what individuals can do and expect. If we don’t change our ways along with it, our ability to influence will be diminished. This doesn’t mean things are now emergent. There have always been things that have been emergent, and a healthy company always has some efforts that fall into the category of throw it against the wall and see if it sticks. What’s changed is the pace at which we can do it. We need to incorporate this into the way we execute. I believe the trend toward business architecture is a clear sign of EA trying to do this. We must remember, however, that the artifacts and techniques used to provide context to developers and engineers may not work with the business. We need to speak the business language, not try to get them to understand ours.

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.

This is another blog on the subject of a service-based view of Enterprise Architecture. Previous posts focused on the actual service definitions (here and here) and a general view on communications, this one focuses on the actual management of those services, specifically on the notion of reporting.

In my experience, as teams try to transition to a service-based view, a key challenge is in moving from an inwardly-focused view to an outwardly-focused view. In other words, shifting to a focus on the customer. An easy way to encourage this shift is to think about your communication to the customer. If you think of examples of great service, it goes beyond the communication associated with service execution. As a simple example, think about your credit card. There are credit cards that simply allow you to make your purchases and then send you a bill. Some cards, however, send you a report every year that gives you information on how you’ve used your credit allowing you to make better financial plans. So, how can we take this same approach to the EA (or any other) service offerings?

The simple part of this is to make a commitment to communication with your customers. At a minimum, think about reporting to your direct customers and their management. In all likelihood, you’ll need to add two additional audiences to this. First, is senior management over EA. Depending on where EA sits in the organization, this could be senior IT leadership or it could be senior enterprise leadership. Second, is the group most people are used to dealing with, and that’s internal management of EA. The more complicated part of this is figuring out what to report and how frequently to report it. I hope to cover this in more detail in a future post, but for now, think about how you can add additional value to the relationship. Rather than simply reporting status of engagements, provide additional value through an analysis of activities, added information from EA research services, or some transparency into the activities occurring within Enterprise Architecture.

I’m an unabashed Kindle fan, but I’ve come to realize that there is room for improvement. The Kindle needs an iTunes equivalent. Not the store, but the desktop companion application. Clearly, Amazon’s original intent for it was as a book reader. For me, however, the usage parallels that of my first iPod. When the iPod came out, there was no iTunes store, but there was iTunes. You took your existing CDs, ripped them into iTunes, and put the content onto your iPod. While there’s no way to “rip” a physical book onto the Kindle, there’s still plenty of electronic content that I deal with each and every day that I’d love to have on the Kindle. Unfortunately, there’s not a good solution for that. Yes, you can email these documents to Amazon and pay a fee for wireless delivery (not cost effective for as many documents as I’d convert), or you can use a program like MobiPocket Creator or Stanza to convert them yourselves, which frankly, is a pain. What I want to be able to do is just drop a Word document or a PDF into a library in this application, and then the next time I connect my Kindle via USB, have those files converted and placed onto the device.

Why would I want to do this? I receive new documents probably every single day, ranging from 2-3 pages to 20 pages or more. Keeping them on the laptop usually means they don’t get read, and printing them out is a waste of paper, and also likely that they don’t get read, as I don’t have them with me when I have time to read. Putting them on the Kindle would be a great solution for me. Plus, the Kindle allows annotations, so if I need to document something to discuss with others, it can do that for me. If this were possible, I think it would open up the Kindle for the corporate market. If there were ways to tie a Kindle to an analyst firm subscription, even better. Amazon would really need to improve the content management on the device, because one big long list quickly becomes problematic, but that can be solved through software. So, Amazon, when can we see the desktop content manager for the Kindle, or are you leaving this up to a third party to provide?