Todd Biske: Outside the Box

Archive for the ‘IT’ Category

I previously posted some thoughts on the new book from the Neils at MacehiterWard-Dutton along with Jon Collins and Dale Vile from Freeform Dynamics called “The Technology Garden: Cultivating Sustainable IT-Business Alignment.” I finally got a chance to pick it up again, and I thoroughly recommend chapter 8, “Foster relationship with key IT suppliers” for anyone who has an involvement in vendor decisions. Working with vendors is an art, and it’s not just the department head who needs to do it. They give some practical guidance on how to determine who your strategic vendors are, and who the vendors are that you simply deal with on a transaction by transaction basis. In addition to this, they also give prescriptive guidance on working with them, and the art of the win-win solution.

In addition to being of value to vendor relations, anyone adopting SOA should also understand this chapter. Why? Because if you’re a service provider, a lot of the same conflicting pressures occur between consumer and a provider. Strive for the win-win situation, and you’ll be better off. It’s not easy to do, especially when you have multiple consumers each with their own priorities.

Simon Brown, on his blog “Coding the Architecture,” had a good, short post on tactical solutions. One of the points he made that I liked was this:

For me, a tactical solution can be thought of as a stopgap. It’s an interim solution. It’s something potentially quick and dirty. It satisfies a very immediate need. Importantly, it has a limited lifespan.

It’s the last sentence that hits home. If you’re calling something tactical, you’d better have a date on the books as to when the solution will be replaced. That’s not easy to do, especially considering how long the typical IT project takes and when funding decisions are made. I had one project where I went to my supervisor and asked him, “Are you okay with paying $$$ for this now, knowing that we will replace it in 18 months to 24 months?” He said okay, and while the real timeline wound up being about 36 months, the replacement eventually did happen. That’s probably the closest I’ve come to truly having a tactical solution. At the time the solution was put in place, a placeholder was put in place for the strategic solution and the process for obtaining funding began.

This brings up a great point for the domain of enterprise architecture. Many architects out there spend a lot of time establishing a “future state architecture.” Often, the future state is a pristine of view on how we want things to be. What doesn’t happen, however, are statements regarding everything that exists today. I’m a big fan of making things as explicit as possible. When I’ve worked on future state architecture, I always ask about the current platforms and what will happen to them. Either they’re an approved part of the future state (and they can be classified as not available for new solutions), or there needs to be a project proposed to migrate to something that is approved. What you don’t want to do is leave something in limbo where no one knows whether it’s part of the architecture or not. The same holds true for so-called tactical solutions. Unless there’s an approved project to replace it with the strategic solution, it’s not tactical, it’s the solution. Don’t let it linger in limbo.

I had a doctor’s appointment today, and in the office, they had a poster asking their patients for patience as they work to implement electronic records. The signs have been up for the last few visits, so I think the bulk of the efforts are complete. From an experience standpoint, I’m very satisfied.

When the effort first started, one of the first things they did was take a digital photo of me at my next visit. In addition to the office staff now recognizing me when I come in the office, I personally feel that this has greater potential for reducing errors. Why? Every staff worker that’s not permanently seated at a desk is carrying around a laptop (Fujitsu Lifebook, I believe). When they are dealing with patients, they should be seeing my smiling face as they enter in various information. That provides a constant reminder of who they’re working with. When dealing with paper files, there’s a risk that someone gets them mixed up, and the people using them don’t realize it. While I’m sure this is a very infrequent occurrence, it’s still possible, and having the person’s photo there the whole time should reduce those occurrences even more.

With today’s visit, the cool thing that happened is that my doctor needed to issue a new prescription, and she simply typed into her laptop and told me it would be at the front desk. When I went to the front desk, they handed me a printout, but also indicated that the printout had already been faxed to my preferred pharmacy. Cool.

Overall, I like what it has enabled. The thing that stood out like a sore thumb, however, was the dependency on the FAX machine. They communicated with my pharmacy via FAX. They issue requests to the lab downstairs via FAX. It would be great if some standards could exist so that the doctor’s systems are directly communicated with the pharmacy network or the laboratory. While the electronic prescription FAX has the medication printed in a nice 14 point serif font, it still gets turned into a bitmap, spat out on a sheet of paper, and interpret by some pharmacy technician. From my standpoint, I’d prefer that the doctor’s office talk directly to the pharmacy’s information systems to make this happen and take as much human element out of it as possible. I’d rather have the pharmacist talking to people about their medications than having to interpret doctor’s handwriting or some poor resolution fax.

The other piece of this that could be improved is to provide a secure way for me to get at the information. Suppose you get a cholesterol test. Often times, the doctor may just tell you, “you’re normal.” Typically, however, it’s important to look at trends. (Aside: Yes, just as you should be looking at the metrics of your IT systems and associated trends when things are working fine, you should be looking at your own metrics and trends for your own physical health!) To look at trends, you need the actual test results. Today, I have to call up and have someone read them to me. It would be far more convenient to have some secure electronic way of accessing it. It’s especially true when you’re dealing with multiple doctors. They have a major data synchronization problem, where the patient is viewed as the authoritative source, but often times, we don’t have all the information because our doctor’s haven’t given it to us, or if they did, it was 6 months ago. How many of us have our own medical record keeping system?

Anyway, kudos to my doctor for trying to push the envelope a bit and leverage technology. Here’s to hoping the trend continues.

Just a quick plug to let my blog readers know that I’ll be part of a panel discussion on SOA trends at The Open Group Enterprise Architecture Practitioners Conference on July 23rd in Austin, TX. The panel will be moderated by Dana Gardner. In addition to myself, the panelists are Eric Knorr of InfoWorld, Tony Baer of OnStrategies, and Beth Gold Bernstein of ebizQ. You can register for the conference at http://www.opengroup.org/austin2007/register.htm. If you’re there, please feel free to introduce yourself, ask questions, etc.

The Dilbert for Tuesday, June 12th was certainly appropriate for any conversation on Governance. In all seriousness, however, if you governance processes resemble this, you’ve got problems.

Back in January of 2006, I had a conversation with Phil Windley on governance for an article in InfoWorld. One of the points that I made was that you do need to get your policies documented and communicated. If the only way someone knows whether the decisions they make are right or wrong is by attending a meeting and hoping someone with authority (if they even know who that is) agrees with them, that’s not good governance, albeit it is governance.

The Dilbert cartoon is titled, “CEO Visit.” Clearly, no one will question the authority of the CEO. So, you could argue that step one of governance has been handled, which is establishing the authority of the people who will govern. It’s not just the CEO, but the CIO, CTO, Chief Architect, etc. The problem doesn’t normally exist with authority at these levels, but at the levels in the middle. The chief architect may be signing off on all policies, but they’re probably not setting every policy. There needs to be a hierarchy of decision making, so that decisions are made at appropriate levels, and only where conflicts arise do things bubble up. The problem with this is that if the policies and guiding principles at the higher levels are not established, everything breaks down at the lower levels, because no one knows who has authority to set direction in which area. As a result, people are constantly pushing the boundaries and trying to gain power and influence, rather than actually creating good solutions. It’s not about doing the right thing, it’s about doing my thing. If no one (with authority) has stated what the “right thing” is, individuals will always think that their thing is the right thing. Step two is about establishing and communicating policy.

In a bit of irony, the CEO in the Dilbert makes the statement, “Opinions are treason.” I hadn’t thought about it at the time, but opinions are the downfall of the enforcement portion of governance. Opinions are good when policies are being established. Opinions are bad when policies are being enforced. Think about it. It’s not going to do a bit of good to tell the police officer, “Sorry, I was speeding because I feel the speed limit should be 20 miles per hour higher on this road because of the light traffic and the limited number of entrances, exits, and intersections.” When that highway is being constructed, however, and speed limits are being established, bring all the opinions you want (although backing them up with facts is even better).

We can’t forget about the process (step 3), however. If you employ architecture reviews, what happens all too frequently is that at the time of a review, the discussion turns in a debate of opinions, which will normally go unresolved unless someone in the room is in a position of authority recognized by all. A review needs to demonstrate that policies have been followed, and where they have not, focus on the reasons why an exception is necessary, not on whether it’s a bad policy. In addition, the review must also address areas where better guidance was needed, so new policies can be created. Ask the question, “In coming up with the solution architecture, where did you have multiple options for which the reference architecture and patterns did not provide sufficient guidance? What factors led you to choose the option that you did?”

So, as I’ve said before, governance is about people, policies, and processes, in that order. Without clear understanding of authority, documented and communicated policies, and processes to keep improving things, you’ll wind up going to your CEO far too many times for decisions until he starts calling you “Doofy.”

I’m listening to Dana Gardner’s SOA Insights podcast here at the airport. This episode is a discussion with The Open Group about their Enterprise Architect certification. One of the initial questions was whether the role of the SOA Architect was any different from the role of the Enterprise Architect. It seemed that the group in the discussion all agreed that an SOA Architect was a subset of the overall Enterprise Architect role. What did surprise me, however, was the debate on what the responsibilities of the SOA Architect are.

In retrospect, I shouldn’t have been surprised as the same debate is prevalent in Enterprise Architecture as a whole. I’ve worked with organizations whose view on Enterprise Architecture was that it was strictly a technology play, focusing on standard infrastructure. In the SOA space, this is concerned with connectivity between consumers and providers, dealing with the nebulous world of the enterprise service bus, SOA appliances, web services management systems, etc. as well as the technology used to build and execute services, including application servers, orchestration engines, and the like. While less common (but certainly not uncommon), I’ve also encountered organizations where Enterprise Architecture was much closer to the business, including tasks such as business process modeling. Here, it’s much more about the application of technology, rather than the technology itself. Once again, looking at this from the SOA space, the focus would be on the services themselves, not necessarily on the technology used to expose them. What’s my opinion? Simple, it’s both. The only debate is on what is the appropriate organizational structure is for these roles and responsibilities. There’s always some subdivision of responsibilities across multiple people. A topic such as middleware technologies has enterprise applicability but sufficient breadth within it given the continuing evolution of development technologies such that you can have a full time architect focused on the strategy around it.

Regarding whether EA should also include the application of the technology, this was a nice lead in to a second point of debate, which was whether a developer background or a business analyst background leads to an EA career path. Again, I think the right answer is both. A business analyst background will pay significant dividends toward the component of EA concerned with the application of technology, although it depends on how much your analysts participate directly in the technology application efforts. While I do think there’s more potential for some with a technical background to become an EA, simply because of the breadth of solutions to which technologies like Java EE or .NET can be applied, there’s far more value in combining that with business knowledge. Furthermore, the further you go on the business side, the more likely that the role of strategic planner for the business is already being covered by someone on the business side. Those people need to be actively working with EA.

The final point of discussion was around the role of education in Enterprise Architecture. The panelists all agreed that experience was a critical factor, and that you can’t teach experience, however there are aspects that can be taught. One panelist gave the example of a course on TOGAF. The one subject that didn’t come up in this or the discussion around the career path to EA was the ability to be a big picture thinker. For me, this is a must have for anyone in the EA role. Enterprise architecture is about the enterprise. If you can’t see the forest for the trees, you’re going to struggle. If you look at the typical IT organization, what’s the percentage of people who are working on project efforts that are narrowly defined? I’d argue that it is well over 50%. Take out the support and overhead activities, and you’re not left with much. Therefore, EA has to fill that strategic planning gap. You need to be comfortable in working in areas where boundaries are fuzzy, if they’re even known at all. Conflicting priorities and politics are the norm. Personally, I think being a big picture thinker is extremely difficult to teach. I think people naturally prefer to focus on either the details or the bigger picture. I focus on the big picture. As an example, my wife and I are redecorating our front room. She painted everything, and then went out and bought a bunch of artwork for it. She and her mother were hanging the artwork and she asked me to come up and offer my opinion on whether the piano should be moved six inches to the left or not. I told her that it all depended on where the artwork was going to be placed and the balance of the room. I couldn’t offer an opinion solely on the piano, I could only offer an opinion whether considering the entire room. I think I even said that moving the piano six inches was insignificant. Someone who is detail oriented probably would have obsessed over those six inches.

There are risks associated with being a big picture thinker, and it’s important that your EA staff recognize it. Strategy is useless unless you execute. This doesn’t necessarily mean going deep into the details, but it does mean that you need to come up with a logical sequence of activities that can realize the strategy. With each activity, however, you’re narrowing the scope so that you can now leverage the other 90% of the organization that is focused on refining scope and making it happen.

Courtesy of Rich Seeley and SearchWebServices.com, I caught up with the recent announcement from IBM Rational at their IBM Rational Software Development Conference going on in Orlando.

Rich paraphrased David Locke, director for IBM Rational Worldwide Marketing Strategy, stating that “the next generation tools that the Jazz project is expected to create will aim at providing real-time collaboration of geographically dispersed project teams through things like embedding instant messaging technology into development tools.” There are a few things that occurred to me after reading this.

First, the idea of “open commercial” is quite interesting. IBM Rational still intends to develop “fully commercial” products, yet they’re doing it through a very open process. As long as the community doesn’t revolt on them for wanting their time without somehow sharing the profits, this could be successful. While I’ve never seen studies on it, I still suspect that the bulk of open source products are still strongly subsidized by paid staff of companies that are making money from it (e.g. IBM, MySQL). I’m sure IBM and BEA both have paid staffers who spend all of their time on Apache projects.

Second, the mention of instant messaging brought up recent memories for me. While I don’t think anyone has noticed, there’s a link at the top of this blog labeled “Talk to Me”. As an experiment, I put a Google Talk widget on the site. Unfortunately, it doesn’t work the way I’d like it to. Effectively, I wanted it to be pre-configured with a buddy list of me, without the ability to chat to anyone else, or maybe just to people visiting my blog. There wasn’t a way to do it. I looked into other systems, but didn’t find a way to integrate with my existing IM clients. To make Google Talk work, I had to post instructions on adding me to the buddy list, which isn’t that great of a solution. Anyway, my point with all of this is that it’s a big challenge on figuring out how to integrate all of these things. I was listening to the latest Monkcast from ZDNet and Redmonk and listening to the guys reminisce that at one time years ago, Microsoft Exchange was winning because of its simplicity. I will certainly agree that keeping things simple can be beneficial, but eventually there becomes a need to integrate all of these smaller, simple items into something that is more functional and efficient. Balancing those tradeoffs is not an easy problem. Here again, I think there is power in the masses and opening it up to the community. The last thing we need is an embedded and isolated IM client, and that’s just one example. Personally, I hope that the community looks into some of the lightweight capabilities provided by things like the MacOS X Dashboard and Vista Sidebar and see if we can get the simplicity of these low-functionality interfaces but yet allow “right-time” integration with the tools we’re using the majority of the time.

Jordan Haberfield of Excel Partner recently posted a blog titled “Enterprise Architects as ‘Impact Players'”. I’ve enjoyed Jordan’s blog as it discusses EA from a different perspective, one of talent and corporate culture, rather than the technical aspects. I’ve always found the human and social aspects of things very interesting.

Anyway, he provides an excerpt from a book he read called “Don’t Send a Resume: And Other Contrarian Rules To Help Land A Great Job” by Jeffery Fox which introduces the role of the impact player. Here’s the quote:

“There is always a job in a good organization for an impact player. An impact player is someone who can quickly improve the economics of a company. An impact player is someone who can bring in customers, energize the sales force, restructure an under-performing department, speed up the innovation process, solve the late shipment problem, or physically move the manufacturing facility to a lower cost area. An impact player also is someone who will do the necessary but noxious tasks no one else wants to do. An impact player is someone who will get their hands dirty, pick up a shovel and start shoveling, open the store early and close late, deliver product on their way home, deal tirelessly with irate customers and make a service call on Christmas Eve. Good executives in good companies want to hire impact players.”

Jordan goes on to state that “Enterprise Architects are in a position to become that impact player and make a significant difference.” It’s probably better stated that Enterprise Architects should be in a position to do this. Whether they are or not is highly dependent on the corporate culture.

I’ve spoken with a number of colleagues in the St. Louis area, and it’s my understanding that many of the organizations here where I reside don’t even have a formal EA group. Why is this important? It’s important because I believe that an impact player often has to transcend boundaries and operate outside of the constraints that a particular job description may imply. If an organization doesn’t have an Enterprise Architecture discipline, someone needs to go outside of the box of their current job description and start doing EA. If the corporate culture is resistant to people operating outside of their formal job description, that impact player is going to need some very thick skin.

A great example is from two years ago when Jason and Ron at ZapThink emphasized the need for the SOA Champion to guide an organization through SOA adoption. SOA is not about buying an ESB, Registry/Repository, or any other tool. For the bulk of companies that comprise the “status quo” of Service Averse Architecture, it’s about a fundamental change to the way IT solutions are delivered which can cover organizational change, process change, and technology change. What organization has a formal role established for this position? Probably not many. It requires someone to be an impact player, think outside the box, transcend boundaries, and pave the path for the new way of doing things.

Some companies encourage individuals to think outside of the box and outside of their formally stated responsibilities, and it’s probably one that should be added to the litmus test for a company likely to be successful with innovation and strategic initiatives. After all, the degree to which a company does this is a matter of trust. Unfortunately, it’s far easier to break down that trust that it is to build it up. For those of you dealing with that, follow this link to another excellent book that I’ve read.

In summary, the original quote by Dr. Fox states that “There is always a job in a good organization for an impact player.” The key part of this is “good organization.” If you are exhibiting the qualities of an impact player, but you’re struggling to be successful, take a look at the organization’s culture and see whether it is a “good organization” or not. If you’re looking for a good organization, you may need to look for the foot-in-the-door opportunity, because often times, it takes an outsider to come in and recognize the areas for potential impact, so you’re not going to find it on Monster or Dice.

James Governor of RedMonk has a post that he claims is the “Most exciting idea in ages: an ATOM/LDAP mashup.“ It’s actually a very interesting idea to me, especially because he suggests applying it to the management domain. I’ve previously posted (here and here) about the convergence of metadata, and how I’ve seen parallels between Service Repository, Configuration Management databases, Asset Management systems, and potentially even LDAP. So, if we’re doing an ATOM/LDAP mashup, is ATOM equally applicable to other items in the metadata management domain. I suspect that it will be. Nearly all management specs I’ve seen have a resource-oriented view, and it would seem that the combination of ATOM and REST could be a very good fit on top of this. Hopefully James will keep us all updated on the progress of this exciting idea.

Some of the blogs I follow have been simply giddy about the recent statements on REST from Anne Thomas Manes of the Burton Group. About the only thing I agree with on some of the comments is that Anne is extremely smart. Beyond that, this is a case of people seeing what they want to see. Of course, some will accuse me of doing the same, but that’s okay. All of our blogs are simply forums for stating our own opinions, so that’s what it should be!

First, let’s call out where the debate exists. The debate has been around REST versus WS-*, not REST vs. SOA or ROA (Resource Oriented Architecture) vs. SOA. Even there, you could narrow it even more, which was eloquently captured by Erik Johnson in a comment on Stefan Tilkov’s blog (which came to my attention courtesy of Don Box’s blog).

“It seems to me that people attracted to REST (in whatever form) are rebelling against interface-based programming more than WS-* itself — at least that’s my excuse.”

There have been endless debates in the blogosphere and mailing lists over whether or the message payload is part of the interface or not. Clearly, REST is all about having a uniform interface, and if you include message semantics in that interface, it seems that it would be a difficult thing to achieve. The uniform interface is GET, PUT, POST, and DELETE. There’s been some recent discussion about media types and their role in implying message semantics, however, the WS-* proponents will argue that there’s a huge gap between application/xml and having XML Schema (courtesy of WSDL).

Anyway, back to the statements from Burton Group. While most of the bloggers are commenting on this news story at SearchWebServices.com, I first caught wind of this directly from the source via the Application Platform Strategies Blog at Burton Group. My take on this is that Anne first recognizes that REST isn’t going away anytime soon, as is increasing in mindshare. No arguments here, and there are plenty of REST bloggers out there popping champagne bottles over this statement.

The piece that I feel is getting lost in some of this discussion is that, as Anne points out in the APS blog:

REST is not the same as “plain old XML” (POX). POX refers to the format of a message payload, and it says nothing about architectural style. It just says that you don’t wrap an XML message with an XML envelope (e.g., SOAP or Atom). More to the point, not all POX applications are RESTful, and not all RESTful applications are POX.

This is probably the biggest myth right now. There are lots of people that are using XML over HTTP, thinking that they are using REST, when in fact, they aren’t. Again, Anne nails it with this statement:

REST is not simply technology–it’s an architectural style that’s fundamentally different from they way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.

This is where I’d like to see some constructive conversations. When we’re talking about SOA, we’re talking about services. Services represent capabilities. Capabilities are typically associated with verbs. REST is resource-driven. To me, that would mean that I should apply it where I need a resource oriented architecture, not a service oriented architecture. The question is where is this appropriate? Clearly, there are many calls that do nothing more than retrieve data, and it would seem that a REST-based approach for this would work very well. The question, however, is whether a resource oriented view is sufficient.

One of the things I like about SOA is that it can help establish better lines of ownership, which theoretically, can allow IT to operate more efficiently. Because these are based on services, however, they are more likely to be aligned along functional boundaries rather than on resource boundaries. Resources are shared across functional boundaries, so if my unit of composition is at a resource level, how do I deal with these concerns? I’m not suggesting that it can’t be done, but I think this is where there is lots of room to grow, as Anne points out. In the SearchWebServices example, Anne provided a light bulb example, which (pun intended) should turn on the light bulb for people on what they’re getting into:

“A REST application to turn on and off the lights in your building will require you to design a URI for every light bulb and then you send it on/off messages,” she explained. “It’s not like I have a single service that manages all my light bulbs. It’s a very different approach to designing a system. And it’s going to be really hard for developers to get their hands around it.”

So what is my opinion on all of this? If it’s doesn’t come across from my blog, I tend to very pragmatic. I think there are places for both WS-* and REST, and that will continue for the foreseeable future. REST makes lots of sense to me when we’re dealing with browser-based clients (e.g. AJAX). WS-* makes lots of sense to me for service-to-service interactions. I do fall more on the side of formal interfaces, and as a result, I want to learn more about WADL. I’ve yet to see a solution that is doing REST by the book, most examples I’ve been fall more into the POX/HTTP category, or using an HTTP GET with query parameters to return data as XML (all read only). That doesn’t mean they don’t exist, I just haven’t seen them. In any case, debates such as these keep things interesting. There’s always risks that it will strictly be a battle of religions rooted in opinions (which never get resolved). Involvement of people like Anne Thomas Manes and others that fall into the pragmatic group in the middle can ensure that the debate progresses to appropriate application of these approaches to where we leverage the strengths of both, and minimize their use in areas where the weaknesses are exposed.

I was recently having a conversation regarding data services and my recent posts (here and here) on horizontal versus vertical thinking put it in a new light. My experience has shown me that data services are one of the most controversial topics within an enterprise.

Nearly all solutions, somewhere along the line, are going to need to access some form of structural data, typically from one or more relational databases. The debate around data services begins with a discussion on whether or not all access to the data should go through a service or not. I’m not going to get into that part of the debate in this post. The point of this discussion lies more with the organizational challenge of creating a data services layer.

One reason (but certainly not the only one) that is sometimes used to justify a data services layer is to maintain control over how the databases are used. All it takes is one bad SQL statement to cause a significant impact to all systems using that database. When organizations see this problem, the instinct is to centralize the development of data services. By creating a team with expertise in database access technologies, the assumption is that you’ll get high quality services that will prevent system failures due to data unavailability. The challenge with this approach is that this assigns ownership and service boundaries along a technical domain: data access. Per my previous postings, assigning ownership based on technical boundaries implies a horizontal domain. Horizontal domains are ones where the capabilities are becoming commodities and can be done in a standard fashion. Service teams in a horizontal domain typically strive to minimize the number of services involved. This is where the challenge occurs. Data access is anything but a commodity. While the techniques used to access data may be standardized (SQL), the structure of data and the combinations of data desired by consumers is certainly not.

In his book Human Interactions,
Keith Harrison-Broninski pointed out that everyone deals with information differently. We file it differently, we take notes differently. Trying to standardize information access is inherently problematic. Why is this? Because information retrieval operates in a vertical domain. We’re retrieving information for the purpose of doing a particular task. So, we have a services team that is viewing the world in a horizontal fashion, with their primary goal being to minimize the number of services they provide. On the other side of the equation, we have vertical thinking consumers that want data for a particular purpose in a format that is optimized for what they need to do. Clearly, if the consumers have the most influence, the goal of the service team to minimize the number of services is not going to happen. If the service team has the most influence, the goal of the consumers to have optimized services is not going to happen. We simply have a situation where the two (or more) teams involved have competing goals. You can’t say that either one is right or wrong, only that they are competing with each other. There can be sound justification on both sides, so the organization must mediate and try to create a win-win situation.

I think this subject is a great example of the concepts of horizontal and vertical thinking. Things can go very smoothly when both the consumer and provider are consistent with their understanding of a particular domain as either horizontal or vertical. When there is disagreement, and one group sees things as horizontal while another sees things as vertical, the relationship is going to be problematic. If you can make it a win-win situation, that is the best scenario. If one party or the other simply has a view that is inconsistent with the view of enterprise architecture, that’s a communications and education issue for EA. EA needs to set the policies for what constitutes good architecture, and if a particular functional domain is deemed to be horizontal (or vertical) that information should be well communicated so the individual solution architect approaches its usage properly.

James McGovern had an interesting post recently entitled “Are Business Applications Boring?” It reminded me of some of my own experiences, both as a supervisor and as an individual. A few years ago, a group that I oversaw was very focused on Java middleware technologies. .NET was gaining in prominence at that time, and it was clear to me that the team would need to gain Microsoft experience, and it was entirely likely that the majority of our work in our future would be on the .NET platform. I told the team that they needed to determine what was more important to them: writing successful Java solutions or writing successful business solutions. In addition, I asked myself that same question. To me, I was more interested in seeing the organization and the business be successful than I was about writing Java code or C# code. For others, they chose to part ways with the company as the amount of Java work reduced. There’s absolutely nothing wrong with that, although, I do think there’s more long term risk for a developer in going that path. Why? It’s far easier to find someone who can write code than to find someone who understands the business and the culture.

Interestingly, I left the enterprise world about 9 months ago and joined the consulting ranks. That being said, if you’ve followed my blog, you’ll know that I don’t view SOA as a technology initiative. Proper application of technology in support of business needs is far more of a business issue than it is a technology issue, and that’s what interests me. My view on SOA consulting is that it needs to be focused on business consulting more so than technology consulting. This subject came up in a recent conversation with Dana Gardner and his analyst gang that will be published soon.

The short of this is that it is difficult for enterprise IT practitioners to hold on to top technical talent unless those individuals are interested in the business. If I were to go back to school today, I would pursue an MBA, not additional technology education. If individuals are solely focused on the technology, they are unlikely to get long term satisfaction from a 30-plus year career at one organization. Unfortunately, I haven’t seen very many developers who are passionate about understanding the business. I can’t remember the last time that I interviewed someone and had them ask me some serious questions about the business to see whether it would be a good fit, when you’d think that would be one of the most important factors.

In my mind, the writing is on the wall. If you’re in the early stages of your career and want to put yourself on a path for long term growth, you’ll need to build up deeper and deeper knowledge of the domains where you apply technology. If you just want to maintain a status quo, you can become a developer, however, I suspect that your salary will remain part of the status quo, as well.

James McGovern made the following comments regarding my Service Adverse Architecture post:

Todd Biske is right on the money by echoing the fact that companies who have mastery of SOA also have forward thinking management. I wonder if him and Joe McKendrick would define a litmus test so that others can characterize their own enterprise in terms of the management team?

While I’ll have to give some thought to the entire litmus test, the first thing that immediately came to mind was trust, and it’s not limited to management. If I’m a project manager, I want to have as much control over my own destiny as possible. When I now become dependent on other groups and other projects outside of my control and my management to be successful, that’s a big leap of faith. Unfortunately, it’s part of human nature to remember the one project where a team had problems rather than on the times the team was successful. As a result, parties may go into the relationship with the expectation that someone is going to screw up, spend all their time looking for it ready to point blame, and as a result, that’s exactly what happens. If the groups instead focused on what is necessary to be successful, they’d probably be successful.

We live in a culture where making a mistake is unacceptable. One only needs to look at the current political process to understand how much our culture is based on avoiding failure rather than achieving success. A legislator is not allowed to change a stance on any issue, even though we as individuals do it all the time because we learn more as we go along. Cultures that are based on avoiding failure are, in general, going to have a difficult time doing more than maintaining the status quo. Innovating and advancing means taking risks, and when you take risks, some of them don’t pan out. Teams should not be penalized when they don’t pan out, unless it’s clear that they made very bad decisions based upon the information available at that time. I can look back at many decisions I’ve made in the past and recognize that some of my assumptions didn’t come true. As long as I’ve learned from that and don’t repeat those same decisions, there should be no penalty associated with it.

I suspect that organizations that are more forward-thinking have a greater level of trust within the organization. There is more collaboration than competition, and people all understand that everyone in the organization has the best interests of the organization as a whole in mind, not the best interests of themselves, their team, or their manager. Furthermore, management works effectively with the individuals in the trenches to help them understand what levels of risk the organization will tolerate and what the boundaries for innovation are within each group in the organization (essentially around roles and responsibilities). I’d much rather have an application developer creating innovative applications rather than trying to leverage a new Java framework. At the same time, the team responsible for development frameworks needs to be open to receiving input from the application developer. If they have mutual trust, the development framework team will be open to hearing about new alternatives, and the application developer will not throw a fit if the development framework team decides that it’s not in the best interests of the company to leverage the new framework at this time.

SOA will create more moving parts associated with the delivery of IT solutions. More moving parts means more ownership and hence, more interaction among teams. If we don’t trust each other, the chances of success are greatly reduced. That being said, trust must be earned and maintained, it can not be established by edict. Service providers must do all they can to build trust. Management must ensure that the organization takes an “innocent until proven guilty” approach, rather than the opposite, with actions that back it up.

I just listened to Elizabeth Book’s podcast with Anne Thomas Manes of Burton Group and Joe McKendrick discussing Service Averse Architecture. They definitely echo statements that I and others have been making for some time. Particular quotes that I want to highlight:

The companies that are good with SOA are likely to be … companies that have forward-thinking management and are good at everything else, as well … The organizations that really could use SOA, that need that flexibility and agility, are the ones not likely to be adopting SOA.
– Joe McKendrick

Joe and I both had posts on this topic back in October of 2006 (see here and here). This is simply the nature of way things progress. You have a certain class of organization that are the leaders that have a high percentage of success at whatever they do. The problem, however, comes with the middle class. What we’d like to see is that middle class of organizations merely trailing the leaders, but still eventually achieving success. Instead, we’re at risk of seeing the “haves” and the “have nots.” Anne calls out that Service Averse Architecture is the status quo, and that’s a shame. As long as it continues to be the status quo, we’re not going to progress as an industry, and if anything, it fuels the fire of those that question the relevance of IT. After all, if businesses continue to thrive despite having continued dissatisfaction with IT support, then is IT really a differentiator worth investing in, or is it simply a necessary cost center where the focus should be on driving costs down to rock bottom levels? I believe IT can be a differentiator, but like Anne, I do believe it’s a very select few who are able to do so.

The same type of thinking does hold true in other business support areas. Is HR simply a necessary evil, or can it be a differentiator? Look at Southwest Airlines hiring practices and the experience they are able to give their customers and you can see the impact. Despite having no reserved seats, their customer satisfaction (and profitability) is far better than most airlines. Thankfully, a few shining stars can go a long way in keeping efforts alive to ensure that we don’t have the “technology haves” and the “technology have nots.” It’s why I am supportive of efforts like the SOA Consortium.

The big issue is that most organization have a culture and an incentive system that absolutely discourages the adoption of good SOA practices. That is, everything is project focuses and every project is completely focused on delivery of that project as quickly as possible at the least possible cost and there is no interest whatsoever in figuring out, “well, what is it that I’m building that should be implemented as a service that other people can use?”
– Anne Thomas Manes

I was happy to hear Anne call out the problems with the project-based culture prevalent in IT organizations that I also commented on in April of 2007. There are huge cultural changes that need to be made, but most organizations are not doing so. It’s an extremely difficult problem, because you need to figure out an incremental way of doing it. Anne goes on to comment:

So much of SOA is tied up in things like Master DM and ID M and a reasonable DA and BPI efforts and all the EA things people are doing. You have to take this cross-organizational perspective and plan what you’re going to do and not just say, “Oh, I’ve got a new project I’m going to let my developers figure out what services to build.” It’s challenging because you have to think globally but you do actually have to implement on a local level. But you just can’t depend on the local people to figure out what they’re supposed to be doing. They need guidance from above.
– Anne Thomas Manes

This articulates the challenge well. You can’t simply say tell the developers to build the right services, even if you’re allowing them to challenge the scope boundaries of the projects, without having appropriate guidance from above. I’ve see a number of efforts where developers are honestly trying to do the right thing, but they don’t know the right next steps to take. The project-based culture is so ingrained that even when they are able to identify appropriate services that have broader value, they don’t know what to do to ensure that those services actually see broad use. Too often, it’s simply a “let’s build it and hope they come” approach, where the only guaranteed consumer is that initial project that kicked it all off. In short, not much has changed.

I talk about this as a lifestyle. If you want to become healthy and fit you need to exercise and eat right. Well, if you want your systems to be agile and flexible, then you have to adopt SOA fitness activities. You have to recognize what’s good behavior, what’s bad behavior, and try not to do the bad things, try to do the good things.
– Anne Thomas Manes

If you’ve been lucky enough to have someone really think about what it means to adopt SOA, you’ll understand exactly what Anne is saying here. SOA winds up touching all aspects of IT. If your doctor tells you that you are at risk of a heart attack, simply eating less fatty foods is not enough. There is no magic pill or single activity that will make your SOA adoption efforts successful. It is a lifestyle, and you need to be committed to everything that it may entail, rather than only doing it where it is convenient. We have to recognize that to make things better for the business, things have to change. If we’re only implementing minor changes, we can only expect minor successes. If your IT department is already very successful, minor changes may be fine. If your IT department is on a path to a heart attack, major changes may be in order.

Update: As usual, the timing of Dilbert is perfect. The Dilbert for Monday, May 22nd really captures the status quo and how there is far too much competition rather cooperation that occurs within the enterprise.

Joe McKendrick posted a followup with some of the discussions that have went on within the comments of his blog regarding his commentary on the recent ZapFlash about barriers to SOA adoption. While most of the comments amount to vendor bashing, the one that stuck out to me was the one that said, “SOA offers nothing different than what the vast majority of good IT teams have been doing for more than a decade. Think strategically? We do. We recognize SOA for what it is: nothing.”

My first comment is that SOA is indeed, evolutionary, not revolutionary. That being said, I simply don’t believe that most IT departments can truly believe that they’re doing a great job. Are there some that are? Absolutely. Are those great ones thinking strategically? Probably so. But what about the rest of the pack? To them, I ask one simple question: What has changed? If you’re viewing this strictly as a technology thing where you throw some REST or Web Services into the same-old solutions that you’ve been building, you’re not getting it. If the business is unhappy with IT, something needs to change. Perhaps its a change in how things get built and how we view lifecycles (such as product lifecycles instead of development lifecycles). Maybe that manifests itself in organizational changes. Perhaps it is more operationally focused with visibility and reporting on subsystems that are of significance to the business rather than another IT worker. These are just some examples. If you’re still defining projects in the same old way, deploying them in the same old way, etc., well then, not much has changed, has it. I hope that 10 years from now some things have changed, but IT moves very slowly. 10 years ago, I was hoping usability and user-centered design philosophies would continue to gain prominence, and those are still in their emerging stages in many corporate enterprises. At least I know I’ll have a long career in advocacy!