Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

A new Greg the Architect video has been posted, called Focus Pocus. I wasn’t aware of this before, but it’s now known that TIBCO is the driving force behind this series of videos. Anyway, watch Greg and his boss visit an SOA conference at “the Biscotti Center” in “beautiful, exotic, tropical … downtown San Francisco.”

Dana Gardner invited me to be a part of his Briefings Direct SOA Insights podcast a while back, and the first episode I was part of is now available. Topics included SOA hype, the SoftwareAG/WebMethods acquisition, and the role of Web 2.0 and wikis in SOA. Details are available here, or you can subscribe to the podcast via iTunes here.

I’ve always enjoyed listening to panel discussions, and now it’s great to have the opportunity to be a regular part of one. If there are particular topics you’d like to hear discussed, feel free to drop me a line and I’ll pass along the suggestion. Dana’s got a great group of people that participate on these sessions.

It’s been a while since I posted something more infrastructure related. Since my original post on the convergence of infrastructure in the middle was reasonably popular, I thought I’d talk specifically about the ESB: Enterprise Service Bus. As always, I hope to present a pragmatic view that will help you make decisions on whether an ESB is right for you, rather than coming out with a blanket opinion that ESBs are good, bad, or otherwise.

From information I’ve read, there are at least five types of ESBs that exist today:

1. Formerly EAI, now ESB
2. Formerly BPM, now ESB
3. Formerly MOM/ORB, now ESB
4. The WS-* Enabling ESB
5. The ESB Gateway

Formerly EAI, now ESB

There’s no shortage of ESB products that people will claim are simply rebranding efforts of products formerly known as EAI tools. The biggest thing to consider with these is that they are developer tools. Their strengths are going to lie in their integration capabilities, typically in mapping between schemas and having a broad range of adapters for third party products. There’s no doubt that these products can save a lot of time when working with large commercial packages. At the same time, however, this would not be the approach I’d take for a load balancing or content-based routing solution. Those are typically operational concerns where we’d prefer to configure rather than code. Just because you have a graphical tool doesn’t mean it doesn’t require a developer to use it.

Formerly BPM, now ESB

Many ESBs are adding orchestration capabilities, a domain typically associated with BPM products. In fact, many BPM products are simply rebranding of EAI products, and there’s at least one I know of that is now also marketed as an ESB. There’s definitely a continuum here, and the theme is much the same. It’s a graphical modeling tool that is schema driven, possibly with built-in adapter technology, definitely with BPEL import/export, but still requires a developer to properly leverage it.

Both of these two categories are great if your problem set centers around orchestration and building new services in a more efficient manner. If you’re interested in sub-millisecond operations for security, routing, throttling, instrumentation, etc., recognize that these solutions are primarily targeted toward business processing and integration, not your typical “in-the-middle” non-functional concerns. It is certainly true that from a modeling perspective, the graphical representation of a processing pipeline is well-suited for the non-functional concerns, but it’s the execution performance that really matters.

Formerly MOM/ORB, now ESB

These products bring things much closer to non-functional world, although as more and more features are thrown at the ESB umbrella, they may start looking more like one of the first two approaches. In both cases, these products try to abstract away the underlying transport layer. In the case of MOM, all service communication is put onto some messaging backbone. The preferred model is to leverage agents/adapters on both endpoints (e.g. having a JMS client library for both the consumer and provider), potentially not requiring any centralized hub in the middle. The scalability of messaging systems certainly can’t be denied, however, the bigger concern is whether agents/adapters can be provided for all systems. All of the products will certainly have a fallback position of a gateway model via SOAP/HTTP or XML/HTTP, but you lose capabilities in doing so. For example, having endpoint agents can ensure reliable message delivery. If one endpoint doesn’t have it, you’ll only be reliable up to the gateway under control of the ESB. In other words, you’re only as good as your weakest link. One key factor in looking at this solution is the heterogeneity of your IT environment. The more varied systems you have, the greater challenge you have in finding an ESB that supports all of them. In an environment where performance is critical, these may be good options to investigate, knowing that a proprietary messaging backbone can yield excellent performance, versus trying to leverage something like WS-RM over HTTP. Once again, the operational model must be considered. If you need to change a contract between a consumer and a provider, the non-functional concerns are enforced at the endpoint adapters. These tools must have a model where those policies can be pushed out to the nodes, rather than requiring a developer to change some code or model and go through a development cycle.

The WS-* Enabling ESB

This category of product is the ESB that strives to allow an enterprise to have a WS-* based integration model. Unlike the MOM/ORB products, they probably only require the use of agents on the service provider side, essentially to provide some form of service enablement capability. In other words, a SOAP stack. While 5 years ago this may have been very important, most major platforms now provide SOAP stacks, and many of the large application vendors provide SOAP-based integration points. If you don’t have an enterprise application server, these may be worthwhile options to investigate, as you’ll need some form of SOAP stack. Unlike simply adding Axis on top of Tomcat, these options may provide the ability to have intercommunication between nodes, effectively like a clustered application server. If not apparent, however, these options are very developer focused. Service enablement is a development activity. Also, like the MOM/ORB solutions, these products can operate in a gateway mode, but you do lose capabilities. Like the BPM/EAI solutions, these products are focused on building services, so there’s a good chance that they may not perform as well for the “in-the-middle” capabilities typically associated with a gateway.

The ESB Gateway

Finally, there are ESB products that operate exclusively as a gateway. In some cases, this may be a hardware appliance, it could be software on commodity hardware, or it could be a software solution deployed as a stand-alone gateway. While the decision between a smart-network or smart-node approach is frequently a religious one, there are certainly scenarios where a gateway makes sense. Perimeter operations are the most common, but it’s also true that many organizations don’t employ clustering technologies in their application servers, but instead leverage front-end load balancers. If your needs focus exclusively on the “in-the-middle” capabilities, rather than on orchestration, service enablement, or integration, these products may provide the operational model (configure not code) and the performance you need. Unlike an EAI-rooted system, an appliance is typically not going to provide an integrate anything-to-anything model. Odds are that it will provide excellent performance along a smaller set of protocols, although there are integration appliances that can talk to quite a number of standards-based systems.

Final words

As I’ve stated before, the number one thing is to know what capabilities you need first, before ever looking at ESBs, application servers, gateways, appliances, web services management products, or anything else. You also need to know what the operational model is for those capabilities. Are you okay with everything being a development activity and going through a code release cycle, or are there things you want to be fully controlled by an operational staff that configures infrastructure according to a standard change management practice? There’s no right or wrong answer, it all depends on what you need. Orchestration may be the number one concern for some. Service-enablement of legacy systems to another. Another organization may need security and rate throttling at the perimeter. Hopefully this post will help you on your decision making process. If I missed some of the ESB models out there or if you disagree with this breakdown, please comment or trackback. This is all about trying to help end users better understand this somewhat nebulous space.

It’s funny how these syndicated feeds can be just like syndicated TV. I’ve decided to leverage Google Analytics and create a post with links to the most popular entries since January 2006. My blog isn’t really a diary of activities, but a collection of opinions and advice that hopefully remain relevant. While the occasional Google search will lead you to find many of these, many of these items have long since dropped off the normal RSS feed. So, much like the long-running TV shows like to clip together a “best of” show, here’s my “best of” entry according to Google Analytics.

• Barriers to SOA Adoption: This was originally posted on May 4, 2007, and was in response to a ZapThink ZapFlash on the subject.
• Reusing reuse…: This was originally posted on August 30, 2006, and discusses how SOA should not be sold purely as a means to achieve reuse.
• Service Taxonomy: This was originally posted on December 18, 2006 and was my 100th post. It discusses the importance and challenges of developing a service taxonomy.
• Is the SOA Suite good or bad? This was originally posted on March 15, 2007 and stresses that whatever infrastructure you select (suite or best-of-breed), the important factor is that it fit within a vendor-independent target architecture.
• Well defined interfaces: This post is the oldest one on the list, from February 24, 2006. It discusses what I believe is the important factor in creating a well-defined interface.
• Uptake of Complex Event Processing (CEP): This post from February 19, 2007 discusses my thoughts on the pace that major enterprises will take up CEP technologies and certainly raised some interesting debate from some CEP vendors.
• Master Metadata/Policy Management: This post from March 26, 2007 discusses the increasing problem of managing policies and metadata, and the number of metadata repositories than may exist in an enterprise.
• The Power of the Feedback Loop: This post from January 5, 2007 was one of my favorites. I think it’s the first time that a cow-powered dairy farm was compared to enterprise IT.
• The expanding world of the “repistry”: This post from August 25, 2006 discusses registries, repositories, CMDBs and the like.
• Preparing the IT Organization for SOA: This is a June 20, 2006 response to a question posted by Brenda Michelson on her eBizQ blog, which was encouraging a discussion around Business Driven Architecture.
• SOA Maturity Model: This post on February 15, 2007 opened up a short-lived debate on maturity models, but this is certainly a topic of interested to many enterprises.
• SOA and Virtualization: This post from December 11, 2006 tried to give some ideas on where there was a connection between SOA and virtualization technologies. It’s surprising to me that this post is in the top 5, because you’d think the two would be an apples and oranges type of discussion.
• Top-Down, Bottom-Up, Middle-Out, Outside-In, Chicken, Egg, whatever: Probably one of the longest titles I’ve had, this post from June 6, 2006 discusses the many different ways that SOA and BPM can be approached, ultimately stating that the two are inseparable.
• Converging in the middle: This post from October 26, 2006 discusses my whole take on the “in the middle” capabilities that may be needed as part of SOA adoption along with a view of how the different vendors are coming at it, whether through an ESB, an appliance, EAI, BPM, WSM, etc. I gave a talk on this subject at Catalyst 2006, and it’s nice to see that the topic is still appealing to many.
• SOA and EA… This post on November 6, 2006 discussed the perceived differences between traditional EA practitioners and SOA adoption efforts.

Hopefully, you’ll give some of these older items a read. Just as I encouraged in my feedback loop post, I do leverage Google Analytics to see what people are reading, and to see what items have staying power. There’s always a spike when an entry is first posted (e.g. my iPhone review), and links from other sites always boost things up. Once a post has been up for a month, it’s good to go back and see what people are still finding through searches, etc.

There was a question on the Yahoo SOA group on the notion of SOA compliance, jokingly introduced in this blog from January of 2006 discussing SOA compliant toasters and cell phones. The important question was whether there is a notion of “SOA compliance” or not.

I fall in the camp of saying yes. There won’t be any branding initiative associated with it, however, because it’s not about compliance with some general notion of what SOA is (such as having a product that exposes Web Services or REST interfaces), it’s about a solution’s ability to fit within the SOA of its customers.

It is certainly true that many enterprises are moving toward a “buy” strategy instead of a “build” strategy. This doesn’t mean that they don’t have any work in planning out their SOA, however. Organizations that simply accept what the vendors give them are going to have difficulty in performing strategic architectural planning. The typical IT thinking may be that this is simply an integration problem, but it’s deeper than that.

Previously, I had a post on horizontal and vertical thinking. In this discussion, I called out that an organization needs to understand what domains of functionality are horizontal, and what domains are vertical. When looking at vendors, if their model doesn’t match up with the organization’s model, conflict will occur. It may not be at an integration level, it may be at a higher semantic level where the way the business wants to use a tool just doesn’t match with the way the vendor chose to provide those capabilities. Having a domain model of the business functionality provides a way to quantitatively assess (or at least get a step closer to it) the ability of a product to be successful in the enterprise. This is the notion of SOA compliance, in my opinion.

On the vendor side of the equation, the vendor needs to be able to express their capability in the form of functionality model that can easily demonstrate how it would fit into a company’s SOA. This applies whether it’s a hosted solution or a shrink-wrapped product. Any vendor that’s using SOA in its marketing efforts but can’t express this should be viewed with caution. After all, architectural compliance is only one factor in the equation, however I think it’s one that can have strategic, rather than short-term implications.

In my experience, neither side is very well positioned to allow a quantitative assessment of SOA compliance. Both parties lack the artifacts necessary, and there certainly aren’t any standards around it. Even just having Visio diagrams with rectangles labeled “such-and-such service” would be an improvement in many cases. More often than not, the vendors win out for a simple reason: they have a marketing department, whereas the typical enterprise architecture organization does not. You can assume that a vendor has at least created some collateral for intelligent conversations with Enterprise Architects, however, you can’t assume that an enterprise has created collateral for intelligent conversations with vendors. It needs to go both ways.

Sorry, I need to rant, although, not as much as I originally thought. I just read the interview with Gartner’s Paolo Malinverno on SOA Governance at SearchWebServices.com. I read his answer to the question “How do you define SOA governance” and decided I needed to blog on this, although he made up for it a bit in his answer discussing “phases.”

Anyway, in his definition of SOA governance, he split it into two halves. The first half is about making sure that important decisions go through to appropriate people and that these people have appropriate input to make those decisions. The second half is making sure those decisions are followed. I wanted to scream out, “Where are the policies???” But, he did mention in his answer to the next question that there is a “phase which defines what the policy is.”

Unfortunately, I really didn’t feel like this article made the whole picture crystal clear, so let me do that here.

1. People.
2. Policies.
3. Process.

Step one is to figure out who your governors are. Before you can have governance, you need to have someone responsible for creating the policies to be governed. Paolo made the statement, “This set of decisions, I wanted them covered.” I think it’s more vague than that. I doubt any organization already knows all of the decisions that need to be made. It’s more likely that they know the desired outcome, and now need someone to work backwards to figure out what policies will enable that behave. For example, there’s the holy grail of IT, reuse. If the desired outcome is reuse of services, you need someone to work backward and figure out where policies are needed to make that outcome a reality.

Step two, therefore is about establishing the policies. The key to this is making sure the policies exist is some form other than the memories of the governors. Put them on paper in the form of patterns or reference architectures. Codify them and rely on tools to automate it. If the only place the policies exist are in the brains of your governors, all you’ve created is a bottleneck. This results in a situation like this:

On the one side up in the ivory tower sits the governors, pontificating away. On the other side are their constituents (the developers) busily working away in the trenches. Only on a rare occurrence are the constituents able to gain audience with the governors in an exercise known as a review. At such review, the constituents demonstrate their mind-reading abilities in predicting what things the governors care about, and praying that they don’t reach the dreading situation of disagreeing governors who hadn’t even talked to each other about their own opinions.

Clearly, we need some documented policies here.

Well, that helped a bit, as the mind reading isn’t necessary anymore, but as is most often the case, the constituents either disagree with the policy, or don’t bother to look at it until it’s time for their review, only then to find out that they are out of compliance. Now it’s time for the filibuster! At this point, the best course of action from the constituent’s standpoint is to simply put it off until the cost of making it compliant is far more expensive than the perceived cost of leaving it non-compliant. It usually entails telling the business sponsor that the project can be released in two weeks or it can made compliant and released in 3-6 months. Thus ensues the debate between the business leaders and the elected officials, yada, yada, yada. And this doesn’t even touch on the subject of policies which the constituents don’t like, and claims that the governors are being overly influenced by lobbyists and out of touch with the people.

To conquer this one, and get the right process in place, I recommend the following model:

In this model, we introduce a third party that bridges the gap and is the key to successful policy enforcement. Keeping policies up to date can easily be a full time job, as is building solutions. What we need is a third role that does a bit of both. I’ll call it the solution architect. These individuals are able to participate in the policy setting process, but they also are the key enforcer on projects. They may have the role of technical lead, but at a minimum, they have the authority to set direction on a project. In this way, they help projects apply policy at the right time, and they help the governors define relevant policy. Formal reviews may still take place, but hopefully, they’re much faster and focused on increasing communication and collaboration instead of being a potentially belittling exercise and demonstration of authority, which isn’t good for the health of the organization.

Most importantly, people must know their role. The governors should be judged on their ability to produce relevant policy in a timely manner. Constituents should be judged on their ability to produce solutions in a timely manner. Solution architects should be judged on a combination of the two.

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.

The SOA Consortium has launched a blog, SOA Consortium Insights. Check it out. For those of you that aren’t members, it will give you an easy way to keep up with the ongoings of the Consortium. The latest entry discusses Richard’s experiences at TechTarget’s CIO Decisions Conference and Gartner’s Application Architecture, Development, and Integration Summit.

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.

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.

One of my colleagues at MomentumSI, Jason Henley, has begun blogging on SOA and other things of interest to him. Give his blog a read.