Todd Biske: Outside the Box

Archive for the ‘Management’ Category

I received a couple comments on my previous post, and rather than respond in the comments themselves, I thought I’d use another blog post to address them since I don’t think many people subscribe to the comments feed. Before I get into them, I also wanted to call out this blog post from Anne Thomas Manes of the Burton Group. Out of a discussion on the Yahoo SOA Group about the relationship between 3-tier and SOA, she posted this entry which included this statement:

I also expect that the concept of “application” is likely to go away. Why is it that we as systems users have to be constrained by the limits of this artificial boundary called an application? Why do I have to shift my focus among multiple applications? Why do I have to copy data from one application to another? Why do I have to launch this stupid browser or that stupid application to get my work done? Why isn’t everything just accessible to me from my desktop (via widgets and gadgets) or from within my preferred operating context (e.g., email)?

It was this that prompted me to put together my original post, since I couldn’t find an entry in my blog that was specifically dedicated to this topic, although I had mentioned it as part of other entries. I had meant to include a link to Anne’s post in my first entry and forgot.

The first comment came from Brian “Bex” Huff who stated:

People understand the term “application,” but the word “solution” is a bit too nebulous.
Applications stand alone… what good is a widget to view an Excel doc, without the Excel application to create the doc in the first place?
I agree that IT should always *think* in terms of dynamic, evolving “solutions”… but the basic building blocks still include “applications”… as well as toolkits, frameworks, libraries, etc.

Bex actually made a statement that is indicative of the current culture, which was “Applications stand alone.” My opinion is that applications shouldn’t stand alone. Why shouldn’t we have the ability to present a UI component that can manipulate spreadsheets anywhere? Yes, there will always be cases where spreadsheet manipulation is the only thing we want to do, but there’s also plenty of cases where embedded spreadsheet manipulation would be better for users. What will enable this is thinking in terms of capabilities, rather than in terms of applications. My opinion is that an application is the result of packaging, rather than a unit of composition.

The second comment came from Rob Eamon. He wrote:

There will always be a collection of components/services that have been designed to work together to provide some set of functionality. And there will always be multiple sets of these. And there will always be a need for these sets to interact, possibly through mediation.
Disaggregating application components and making them independently accessible in many contexts seems very appealing.
But take the issues that the typical application development/support team faces and blow that up to the enterprise level. The fragile nature of such an approach will inherently stop it from becoming a reality.
IMO, the application is still a useful and reasonable building block and allows us to break down the enterprise solution space into manageable chunks.
Some of the application components might be useful as independent entities in a larger setting, but I donít think approaching everything that way is a wise course. IMO, it would inhibit flexibility rather than promote (counter-intuitive such that may be).

I wish Rob would have went into more detail on the “issues” that the typical application development/support team faces, because I can only guess what they may be. My first guess is that application teams currently have to deal with ever changing requirements and needs. If you increase the number of parts, you now have smaller components with new relationships associated with their use, and if we don’t manage it well, chaos will ensue. It should be noted that I’ve never said that this type of shift would be easy, and if anything I’d say it’s going to incredibly difficult. I’ve reflected on this in the past, specifically in this post, and wonder if it will take some company approach IT like this from the beginning, without any baggage to create the impetus to change.

Rob went on to state that in his opinion, the application is still a useful and reasonable building block. Here’s where I disagree, for the same reasons I used in Bex’s comments. An application is typically a “packaging” exercise, and those packages aren’t what we want for composition. The only part of an application that still has significant potential for being a “stand-alone” entity is the UI. I’d be happy to see an IT organization that makes an organizational/funding separation between development of UI code from development of services that are used by the presentation tier, much as Jeff Schneider suggested in this post from early last year.

Where I’ll agree with Rob is that this is not a change for the weak of heart. If a new CIO came in and reorganized the organization along these lines, the chaos that might ensue could certainly result in the perception that IT is even less agile than they were before. So, this isn’t a change that will occur in a year. This is a gradual, evolutionary change that will take time, but it will only happen if we’re committed to making it happen. I think a key to that is to get away from the application mindset.

Thanks to Rob & Bex for the great comments, and I’d love to hear from others whether you agree or disagree with my opinions.

I had the opportunity recently to learn more about the role of internal audit in an organization. It was a very interesting and educational experience, and got me thinking a lot about the relationship between the two.

What’s the visual that comes to mind when we hear the word audit? People in the USA probably think of an audit by the Internal Revenue Service. They would also rather go to the dentist and have a root canal done without anestesthia than be audited. So, you can certainly argue that the internal auditors have their work cut out for them. The presenter pointed out, however, that the role of internal audit is changing with time. While a few years ago, they may have been viewed as a reactive police force, today, there’s a shift toward a proactive consulting organization. Rather than coming in after the fact and telling organizations whether they’re compliant or not, they’re now being asked at the beginning, “What do we need to do to make sure we’re compliant?”

There are strong parallels to what goes on in the world of enterprise architecture. First off, many organizations have the dreaded architectural review board, the reactive police force of architectural governance. Projects teams dread them. Somehow, we need to move from this model to the latter model where projects teams know they need to be architecturally compliant and are actively seeking out the input of enterprise architecture to ensure this is the case from the beginning.

Unfortunately, the challenge for Enterprise Architecture is that there is no corporate mandate for EA in the same way that there is for Internal Audit. While I personally thought David Linthicum’s posts on EA as a corporate responsibility were a big stretch, you could certainly argue that if enterprise architecture was a corporate responsibility in the same way as Sarbanes-Oxley, then there would be no debate on whether an organization needed Enterprise Architecture. I found it very sad that at the Gartner EA Summit closing session, when Gartner posted a predication that 40% of EA programs will be stopped by 2012, about 40% of the audience agreed. Note that prediction didn’t say “changed” or “restarted,” it said “stopped.” A publicly listed organization on the NYSE can’t stop the Internal Audit program, it is required.

Overall, my takeaway from this session was that EA and Internal Audit need to be best friends. If Internal Audit has an IT audit group, which most do, it needs to be working closely with the EA group, as both are providing governance. In one of my panel discussions at the Gartner event, I made the comment that EA is certainly about governance. It could be argued that EA activities are basically centered around two major activities: strategic planning and governance. While Internal Audit probably has less of a role in strategic planning (except where governance issues are necesseary), clearly, there’s significant overlap in the governance function. Determine how both groups can work together to ensure that projects aren’t bombarded with governance from multiple groups. The view of the governed is already very negative, we need to do what we can to change that view.

In a comment on my “EA and SOA Case Panel” entry, Surekha Durvasula asked me a couple questions. They didn’t come up in the panel discussion, so I thought I’d respond in a separate entry, as the topic should be of interest to many of my readers. She wrote:

Is “reuse” of a business service considered a valuable metric? How does governance influence the “reusability metric”? Did this come up during this SOA panel?

Specifically, I am wondering if service governance has any bearing in terms of not only promoting the usage of a service but also in ensuring that the enhancement of a service is in keeping with the enterprise-worthiness of the service. Often times it is the evolution of the service where cross-domain applicability is sacrificed.

Also, is there a trend in the industry in terms of promoting business service usage via the use of a “rewards program” or in tying it to compensation packages? Have some industries reached a level of maturity in terms of service reuse especially in those industry verticals that are hit with global competition forcing them to reduce overall operations costs and/or to offer novel product offerings?

Let’s take these one at time. On the subject of reuse, I absolutely think that number of consumers is a valuable metric. At the same time, when dealing with reuse, one must be cautious that it isn’t the only metric of interest. I’ve been in meetings with individuals that have made comments like, “If a service isn’t reused, why are you making it a service in the first place?” I strongly disagree with statements like this, as do most pundits in the SOA space. To defend this position, I frequently quote the oft-referenced Credit Suisse SOA efforts, where they stated that their average number of consumers per service was 1.5. This means that there will be many services that aren’t reused, and probably some that are used by many consumers. While reuse is important, we also have to be looking at metrics for agility, which loosely stated, is the ability to respond to business change. This will involve tracking the time it takes to develop solutions. The theory is that by breaking a solution apart into autonomous services, I reduce the number of touch points when the business needs change. In reality, it depends on the type of change. For example, most of us would agree that a separation of presentation logic from the core business processing is a good thing. That being said, there certainly are plenty of changes that will require touching both the presentation logic and the business logic. One of the most difficult parts of SOA is knowing where to draw service boundaries, because the rules are always changing.

Back to the subject- if we have reusable services, what role does governance play in ensuring that the service doesn’t fork into a bunch of one-off, consumer-specific variants? This is a very interesting question, one that I hadn’t thought much about in the past. My gut is telling me that the burden for this belongs with the service manager, not with a governance team. That’s not to say that there shouldn’t be any involvement from the governance group, but I see a much stronger role from governance in establishing the original service boundaries and assigning service ownership. For future versions, the service manager must be the one that can recognize when the service is getting outside of the boundaries that were originally intended, and this will happen. In some cases, boundaries may need to be redefined. In other cases, we may need to push back on the consumers. All of this starts with that service manager. The service manager must balance the needs of the consumer against the cost of service management. Measurements for determining that manager’s performance should include the number of versions currently being managed and the time required to respond to consumer requests. It is then in their best interests to keep the service focused on its original purpose.

Finally, regarding “rewards programs” or incentives, I don’t know that I’ve ever heard of a case study centered around reuse that didn’t involve incentives. SOA is about culture change, and it’s extremely difficult to change culture without incentives. One only need to look at a government to understand how change occurs. No one would be happy if the federal government mandated that all cars sold starting in 2008 had to get 50 mpg or higher. This is the “big stick” approach. I’ve got a big stick and you’ll get whacked with it if you don’t comply. In terms of IT incentives, one manager I worked with summed up the “big stick” approach well, “Your incentive is that you’ll keep your job.” More typically, the government takes a “carrot” approach, at least at the beginning. Tax breaks are granted to companies that produce high mpg vehicles and to consumers that buy them. These incentives may not even cover the added cost of that approach (e.g. does a $500 tax break for 4 years justify spending $3000 more on a vehicle?), but just the fact that they exist can often be enough to encourage the behavior. Only when enough momentum has gathered does the stick come out, essentially stating a policy that is what the majority of the people are doing already. Overall, I think that incentives should be viewed as a short-term tool to get momentum behind the change, but should always be planned for phase-out once the desired behavior is achieved. Have we reached that point with SOA? I’ve yet to see a company that has. Have we reached that point with reusable libraries? Partially. Most developers would not build their own low-level frameworks today. The problem, however, is that multiple frameworks exist, and there’s still strong resistance in many organizations to having a single solution coming from a frameworks team. I heard my first talk on reuse back in 1998, so it’s very clear that widespread culture change takes a long time to do.

In this session, Robert Handler (of Gartner) is talking about the relationship between Enterprise Architecture and Project Portfolio Management (PPM). First off, there is clear overlap between the two efforts, provided that your PPM efforts are involved with the actual project definition and approval efforts, and not simply involved after project are approved and underway. Both efforts have the common desire to define projects that are intended to progress the company from a current state to a future state, although the criteria involved in project selection probably varies between the two.

On the PPM side, the biggest challenge is that this often isn’t happening. The survey quoted in the slides showed that the bulk of the time in PPM is spent mediating discussions on project priority, and just over 50% of the projects are even under the purview of the PPM effort. On the EA side, the slide states that most efforts are “mired in the creation of technical standards,” operating too much in a reactionary mode to current projects, and have very little effort on gap analysis. So, the end result is that neither effort is necessarily meeting their objectives, especially in the areas where they overlap, and neither effort is communicating well with the other.

He’s now showing an anchor model, and demonstrating how projects can be mapped onto the anchor model to show areas of concern and overlaps. I mentioned this anchor model in my blog entry on the Beginner’s Guide to Business Architecture session, and it’s jumping out again. This is definitely something that I need to get more information on, and hopefully start leveraging. He also presented a common requirements matrix and scoring approach which can assist in prioritization. The one challenge I see with this latter approach is that the projects all have to come along at the same time, which isn’t always the case. We’ll see if he gets to my question on this subject that I just submitted. (Note: he did, and pointed out that it doesn’t assume that everything comes in the same time, but that you do need to be willing to make adjustments to in-flight projects such as removing resources, altering scope, etc.)

Back to EA side of things, he’s advocating the use of patterns, principles, models, and standards as part of the architectural guidance that projects use. No arguments from me here. His slide also states that resource utilization in one organization went from 67% to over 80% when these are used effectively.

His closing recommendations are pretty straightforward. First, EA needs to be coordinated with PPM activities. Someone needs to take the first step to establish some synergies. Second, use coarse-grained EA deliverables for better project selection criteria. Third, use fine-grained EA deliverables on projects as gating factors. Fourth, capture some baselines and measure overall improvements, such as how long the design phase takes, productivity, etc. Finally, evolve maturity and effectiveness from where you are toward the ideal.

Overall, this was a very good session. It could have been a bit more prescriptive, but in terms of clearly showing the relationship between PPM and EA, it hit the mark.

On Wednesday, Patrick Lencioni, author of The Five Dysfunctions of Team, and other management fables gave the morning keynote. It was an excellent talk. Having read both Five Dysfunctions and Silos, Politics, and Turf Wars, I recommend picking up all of his books if you have an interest in making your organization work better (and you should). I picked up his latest book, The Three Signs of a Miserable Job and Death by Meeting after his session and had a nice conversation with him about some experiences.

James asked some of us EA bloggers to try to classify what we do on a daily basis. My breakdown is this, although as I grow in my new job, I would expect this to shift a bit:

• 30% Domain Expert
• 30% Analyst/Strategist
• 30% Technology Expert
• 10% Problem Resolution/Mediation

Note that I used the term “problem resolution/mediation” rather than “troubleshooting.” That was done intentionally to differentiate between troubleshooting operational systems (i.e. production support) versus mediating disagreements between teams, etc. which is far more common for my role. I also added “strategist” after “analyst”, meaning that I’m doing analysis for the purpose of strategic direction. It’s interesting to think about how this will change over time, and the fact that there’s a blurring across these categories. For example, is being an expert in a domain a pre-requisite for being a strategist? It certainly helps, but there are people who simply have a good sense for trends and can easily see where the adoption challenges will typically be, regardless of the domain. I’ll have to make a mental note to revisit this classification a year from now.

It has been a couple years since I attended a Gartner Summit, and now I’m remembering past experiences. Many of the subjects are presented at a very high level (which is appropriate for the audience at a Gartner conference), and many of the subjects are ones that I’ve spent a lot of time researching on my own. I’ve been trying to attend more sessions this time on subjects that I don’t know much about, so the experience has been better. What I’m wondering, however, is why more of the people attending (and there are easily more than a thousand of them) don’t start reading my blog and that of my colleagues in the industry to pick up this knowledge (in addition to attending conferences like Gartner Summits) and even more importantly, ask questions. Yes, reading my blog doesn’t allow you to travel to some interesting location, but I like to think that the content I provide is appropriate and meaningful.

I hear many questions getting asked over and over at these conferences, and it’s apparent that there’s a very large group out there that simply don’t look for the answers to their questions beyond these conferences. Rather than look for the information, they look for an information source. Guess what folks, this is the information age, and there’s a wealth of it out there. I built up my knowledge not only with research from Gartner, Forrester, Burton Group, ZapThink, and others, but also by reading whitepapers, articles, blogs, and anything I could get my hands on. You can do it as well. Gartner, my blog, conferences, webinars, etc. are all sources of information, and the most important thing is to find information that hits home for you and seems applicable to your environment. If it’s one case study instead of one hundred, it doesn’t matter, as long as it is relevant to your scenario, not someone else’s. Gartner is an excellent source of information, and I like to think that this blog is as well. Use both, and then some, and lets keep things progressing forward so at next year’s Gartner conferences we’re talking about new questions, rather than rehashing the same ones.

I attended a session from Michael Blechar titled “The Yin & Yang of Processes and Data: Which Will Be King of the Next Generation Applications?” A big title, and as a result, Michael covered a lot of topics. While there wasn’t any new information for me, I would say that this was one of the better big picture overview presented at the conference. Some of the topics he hit on:

• The challenge of multiple metadata systems, and how some of the vendors are approaching it, in particular IBM. He specifically touched on CMDBs (Configuration Management Database), Service Registry/Repository, Software Development Assets, Database Metadata Management, and more. IBM’s approach is to provide a collection of metadata services that reside above all of this systems, providing a federation layer. Hmmm…. this sounds vaguely familiar, I think I called it Master Metadata Management and spoke more on it here.
• The challenges in determining when to use them versus pushing the logic up into a service layer. It discussed the importance of service ownership.
• The importance of information modeling and its importance in SOA.
• The importance of service ownership/stewardship.
• The importance of enterprise architecture operating as a team, and not having silos of business architecture, technology architecture, and information architecture that don’t talk to each other.

Overall, this was probably a good session for many people and hopefully helped them see a bit more of forest for the trees.

The Power Breakfast is over and done. If you saw me there, hopefully you got something out of the conversation, although it was unfortunate that the session wound up being four independent case studies without a lot of time for audience questions, rather than a discussion among the panelists and the audience. Despite this fact, there were some good points that came out, and I wanted to highlight the ones that struck home with me here:

• First, as the preliminary results of the SOA Consortium funding survey have indicated, there’s no uniform initial approach to SOA. Some leverage an SOA program, some expect service development out of existing projects, etc. One of the panelists, Leo Schuster from National Bank, indicated that they had an SOA Program. In my experience, I’ve never encountered a funded program whose sole goal was to produce SOA. I’ve always worked with business projects/programs that wanted to leverage services as part of their efforts. Personally, I prefer the latter, because as Victor Harrison from CSC pointed out, programs end. Will your SOA efforts ever stop? They shouldn’t. So, while you may have solved the initial funding problem, you haven’t solved the ongoing funding problem.
• Second, metrics are critical. Every single one of us mentioned metrics. Without them, how can we say that we’ve accomplished anything? The oft-mentioned notion of agility is frequently associated with the time to deliver a particular solution. To show that we’re more agile, we need metrics of how things have been and how things are in the future. Beyond efficiency metrics, there’s also metrics associated with service consumption: number of consumers, usage by consumers, min/avg/max response time, etc. In my own experience, merely making these metrics available, and now at a finer level of granularity than the entry points into a web application were very beneficial. This visibility didn’t exist before, so anything was better than nothing. If you’re already collecting this, now you can start to do baseline comparisons to show improvement.
• Third, service ownership is key. It was great to hear someone else say that the project-based culture of IT can be in impediment to SOA success. While your SOA shouldn’t have a lifecycle, individual services do have a lifecycle. If you simply have someone who is responsible for service lifecycle management, you’ve got the key piece of the puzzle for many of the discussions around service granularity, funding, etc. If you don’t have a service owner independent of the consumers, then each consumer is going to try to push things in the direction that has the most benefit for their project, but yet no one will own the service. This in-fighting can be very detrimental to SOA.
• Finally, lets get Service Portfolio Management (SPM) right from the get-go. There are many sessions here at the summit concerned about application portfolio management. We’re all behind the eight-ball here as all of these applications have been built/bought over 5, 10, 15, 25, … years without anyone managing them as a whole. The last thing we want to do is repeat the process all over again with services. We’re at the early stages of SOA and can now do it right. Anyone saying that they don’t need a registry/repository yet because they haven’t reached “critical mass” is potentially making a big mistake. They only need to look at their struggles in trying to do application portfolio management as an example of the path they are heading down.

To those who got up early for breakfast and attended, I hope you found some nuggets in the presentation that were valuable from me or from the other speakers. I’d be happy to have followup conversations with anyone who felt like their questions are still unanswered, or those who want more depth on some of the things they heard.

I attended a session on assessing maturity in IT given by Susan Landry. She outlined their maturity model which covers eight different dimensions. The maturity model has familiar levels if you’ve looked at my work, CMMI, or COBIT. Level 1 is ad hoc, level 2 is repeatable, level 3 is defined, level 4 is quantitatively managed, and level 5 is optimizing. The eight assessment areas are:

1. Application Portfolio Management (APM)
2. Project Portfolio Management (PPM)
3. Staffing, Skills, and Sourcing
4. Financial Analysis and Budgets
5. Vendor Management
6. Management of Architecture
7. Software Process
8. Operations and Support

The most interesting part of the discussion, however, was a single slide that discussed the interdependencies between these areas. For each pair of areas, the relationship was classified as either highly interdependent or moderately interdependent. Having done a multi-dimensional maturity model before, a big challenge is in determining whether or not it makes sense to get scored high in one dimension or low in another. In my SOA maturity model, I typically found that when scores were two or more levels apart, it was probably going to cause some imbalance in the organization. If the scores were even or a single level apart, it was probably workable. What I didn’t do, however, was to explore those inter-relationships and see if that theory uniformly applied. While Gartner didn’t provide a lot of depth in the inter-relationships, they did at least make a statement regarding it which can provide a lot of assistance in determining how to interpret the scoring and what actions to take.

In this session, Frank Kenney and Val Sribar, are discussing agility and application development in the context of a fictitious fable of a web unit in a business organization that is operating in an agile manner and how it works with the traditional application development organization. While I find the fable a bit far fetched, since I’ve yet to see a business unit pushing agile processes on IT, it’s usually the opposite, there is one key point that they made. They called out that not all business units may be ready for an agile approach, simply because they don’t change that rapidly. Hopefully, this will be a common theme throughout the conference. Any approach that claims to be one size fits all is probably going to run into problems. Whether it is agile, REST, Web Services, SOA, EDA, etc., there are always scenarios where it works well, and scenarios where it doesn’t work so well. A key to success is knowing not only how to apply a particular technique, but knowing when to apply it.

Further in on the presentation, they went through some different areas and discussed how they contribute to agility. In the subject of business process actions, they called out that there should be a single business person clearly in charge of a particular process. I think this applies not only for processes, but for services as well. There needs to be a service manager for each service in the organization. An individual may manage multiple services, but without a service manager, there will be problems.

On the subject of reuse, Frank Kenney pointed out that incentives, metrics, testing, methodology, and inventory management (registry/repository) is necessary to make it a reality. I think this is a good list, although I would have liked to see marketing included. While a registry/repository and methodology do focus on the consumption side, if a service or reusable asset is placed out there in a way that makes it difficult to find, the burden is on the provider to improve it, which involves marketing.

Near the end of the presentation, Val and Frank presented an “Application Group of the Future.” Val called out breaking out groups for User Experience, Business Processes, Business Information, an Integration Competency Center, Business Relationships, Software Quality, and Information Infrastructure. These groups would all be operating in an agile manner. In addition, the traditional development groups would also exist. These groups would all leverage common environments to support their efforts. There was one thing about this picture that I disagreed with, which was the placement of SOA. They sprinkled the entire organization with SOA experience, which makes sense, but they didn’t call out the separation between organizations focused on service consumption and organizations focused on service production. If anything, service production (unless it happened to be an automated business process) was buried in the tradition development group, and I don’t think that will cut it. On the bright side, one of the things that they called out which was very interesting, was the need for dynamic budgeting. Val made a comment that the web and mobile applications are challenging the way we book business early in the presentation. This need for dynamic budgeting is an analogous example to how a new agile IT, challenges the way we traditionally do budgeting. Annual budgets won’t cut it, we’ll need to make it more dynamic and responsive in real-time.

In his links post, James McGovern had some comments on my Long Tail of Applications post. He stated:

Todd Biske wants to eliminate the term “application” as it implies a monolith. I would like to point out to Todd that there is another usage of the word that still remains important which primarily indicates a funding model. It is possible and viable to build a great SOA while still letting the finance folks think in terms of applications. Removing the term from architects is a great thing but very disruptive for other parts of the enterprise.

I’m glad James brought up the whole funding model aspect of it. As he rightly calls out, the removal of the term “application” is probably not terribly disruptive for architects, it’s very disruptive for the rest of the organization. How many IT departments have organizations with application development in the title? How many project charters contain the words “…deliver an application…” in their text? If you agree with the premise that, in general, IT is not delivering at the level it could be, then something needs to change. We need a disruption. If that disruption ripples all the way up to the way projects are defined and funded, then so be it. This type of change doesn’t happen overnight, and is not going to be without many bumps in the road.

Does everyone need this type of disruption? Perhaps not, but I think that it’s a very difficult thing to determine. If you’ve read The Innovator’s Dilemma or The Innovator’s Solution, you know what I’m talking about. While I can envision what an organization that has truly embraced SOA and BPM technologies might look like, it’s far more challenging to determine what the path to that state is, which can also leave you wondering whether it’s even necessary. Ultimately, it only becomes necessary when some unknown competitor embraces it and starts beating the pants off of you. Finding that first example that justifies trying a new way of doing things is hard enough, finding the second and the third to justifying sustaining it is even tougher. I’m up for the challenge, though!

James McGovern responded to my Certified Architect

post with one of his own. He made a great point at the end of his entry which was something I wanted to discuss in my original post but didn’t find a way to work it in. He stated:

I guess the point that I am attempting to make is that certifications are neither good nor bad, and it is important to look at each within the context of the role you expect this individual to play. It is my belief that certifications don’t prove hands on skills at all, but having multiple at least says that there is evidence as an Enterprise Architect that you have the ability to learn as well as the desire…

Personally, I think the ability to learn, and learn quickly, is a critical skill for an architect. While some may think that architects spend all of their time up in clouds working on strategies and reference architectures, many of the architects I know are the go-to people when projects are struggling with decisions and direction. An architect needs to be able to quickly understand what it is that project is trying to do, determine what the most critical factors are, and provide appropriate guidance. At other times, it may not be the tactical project, but rather the senior executive asking the question, “should we be paying attention to any of this Web 2.0 and Social Networking hype?” The architect must quickly develop enough knowledge to make good decisions. Probably all architects will get stung at some point by some lower-level detail, but the good architects probably also take it in stride because they’re always learning.

When I interview people, I always ask a question about how the individual stays current, and it’s amazing how many people struggle with that question. If you’re not taking the time to learn, you’ll get left behind. I hope the readers of this blog learn things, and that’s a big reason why I do it. It’s even better when I get comments, links, or trackbacks, because I’m able to learn as well.

I received a press release from The Open Group a couple of weeks ago regarding their IT Architecture Certification (ITAC) program. This is a subject that I haven’t discussed on my blog until now.

Personally, I’ve never been a huge fan of certifications. Back when I was assisting in the interviewing process for Java developers, I saw quite a few developers who were best described as “book smart.” That is, they had memorized sufficients amounts of the certification guides from Sun, but taken outside of that certification context, their ability to contribute value was questionable. It seemed to me that these certifications were really only of value to consulting/contracting firms, because it gave them some kind of a stamp to indicate that the people they were providing had some level of qualification. Of course, the organizations doing the certification gained value as well, as people paid for the training/testing/etc.

When people discuss a need for certification, it ultimately comes back to a need to make the process of finding suitable candidates easier. In my experience in corporate IT, there’s always been at least one group that does pre-screening of candidates before they ever show up on the desk of the team performing the interviews. It’s likely that this includes HR, and also likely that it includes a number of contracting/placement firms. After all, the value proposition of these placement firms is that they provide “qualified” candidates, versus just opening the flood gates to resumes from the Internet. The real problem in all of this is that certifications are disconnected from how people work on a day-to-day basis.

Take the P.E. (Professional Engineer) designation as an example. In the context of a civil engineer, there are certain things that only a P.E. is allowed to do regarding designs, otherwise the company producing that design puts themselves at significant legal risk should that design fail. No respectable civil engineering firm is going to have designs that haven’t been signed off by a P.E. The same thing does not exist in the world of IT. Not only is there no standardized “sign-off” process, but there also isn’t any kind of liability (other than potentially losing your job) if you deliver an IT solution that fails.

If there is no standardization in the way that we perform the work, how can any of the potential value in certifications be realized? Where I see organizations and individuals struggle is where there’s a mismatch between the culture of the organization and the desired culture of the individual. I’ve seen people that are viewed as industry experts struggle mightily because the way that they like to operate simply doesn’t match with the way that the company operates. I’ve also seen teams that may not have had the strongest technical people be far more successful because they simply work better as a team.

At the architect level, my experience has shown that the successful architects tend to be the ones that excel at leadership, influence, and communication. They have to be strong technically, but technical knowledge alone does not make a successful architect. From a technical perspective, it’s probably even more critical that the architect can learn quickly and focus in on the critical aspects of the solution, rather than simply having significant technical depth and experience. How do we assess this? While technical knowledge can be tested, the interpersonal skills are very subjective. On top of that, not only may two people judge interpersonal skills differently, the aspects of what an organization finds important in interpersonal skills will vary. This factor makes it very difficult to come up with a certification process that will really add the value that the proponents claim is possible.

I won’t go so far as to say that certifications have no value, but in terms of IT solution development, they’re simply another tool. A blanket rule that sifts out any resume that doesn’t include certification Foo is probably going to result in you missing out on many good candidates. Because of the lack of standardization in job descriptions and processes, certifications are simply another data point to be factored into the equation. James McGovern has commented on how he likes when potential candidates have blogs. The lack of a blog shouldn’t rule out a good candidate any more than the lack of a certification does. The existence of a blog, certifications, speaking experience, etc. all must be examined.

Jason Bloomberg of ZapThink, in their latest ZapFlash, put a new spin on their old concept of the SOA champion and put forth a job description for VP of SOA. While he certainly suggested a good base salary for the position, I question whether a permanent, executive position around SOA makes sense?

If you look at the job responsibilities listed, the question I ask is not whether these tasks are needed, but rather, whether a dedicated person is needed for all of them. Let’s look at a few of them:

Provide executive-level management leadership to all architecture efforts across the enterprise. The directors of Business Architecture, Enterprise Architecture, Technical Architecture, Data Architecture, and Network Architecture will all be your direct reports.
Don’t we already have this? It sounds like a Chief Architect to me.

Drive all Business Process Management (BPM) initiatives enterprisewide. Coordinate with process specialists across all lines of business, and drive architectural approaches to business process.
Again, to me, this sounds like the responsibility of the COO.

Establish and drive a SOA governance board that incorporates the existing IT governance board.
This is the only one that I simply disagree with. If we’re speaking in terms of IT governance as defined in Peter Weill’s book, I think the IT Governance Board should be factoring SOA strategy and governance into their decisions. That is, IT Governance subsumes SOA governance, not vice versa. Of course, there are also aspects of SOA governance that are implemented at a much lower level within projects to ensure consistency of service definitions, etc. Once again, however, this should be handled by the existing technology governance processes. We’re merely adding some additional criteria for them to be applying to projects.

Establish and lead the SOA Center of Excellence across the enterprise to pull together and establish core architectural best practices for the entire organization. Develop and enforce a mandate for conformance to such best practices.
This gets into the technical governance I just mentioned. I certainly agree that a SOA COE can be a good thing, but you certainly don’t need a new position just to manage in it. Why wouldn’t the Chief Architect or a delegate lead the COE as part of their day to day responsibilities?

Manage a budget that is not tied to individual line-of-business projects, but is rather earmarked for cross-departmental SOA/BPM initiatives that drive business value for the enterprise as a whole.
The question here is whether or not the current organizational structure prevents cross-departmental initiatives from being funded and managed properly. It implies that the individual LOBs will be more concerned about their own needs, and not that of the broader enterprise. If the corporate governance principles and goals have stated that the use of more shared, cross-cutting tehcnologies are needed, then it’s really a governance problem. While an organizational change can assist, you still need to ensure that LOB managers are making decisions in line with the corporate goals, rather than that of their individual LOBs.

Work closely with the VP of Project Management to insure close cooperation between architecture and project management teams, and to improve project management policies.
Once again, why can’t this be done by the existing architectural leadership?

There were additional items, but my thoughts kept coming back to “shouldn’t someone already be doing this?” If the answer to this is “no,” then you must ask yourself whether or not you’re really committed to SOA adoption. If you feel that you are, but don’t have anyone assigned to these responsibilities, does the creation of a new position make sense? For example, if the organization struggles with getting LOB managers to produce cross-departmental solutions, will throwing one more person into the mix fix the problem, or just add another point of view?

As with many of the ZapThink ZapFlashes, there’s always a bit of controvery but lots of goodness. In this case, the articulation of the responsibilites associated with managing SOA adoption are excellent. Do you need a new position to do it? As with any organizational decision, it depends. If you are committed to SOA, but can’t make it happen simply because all of the possible candidates are simply to busy to take on these new responsibilities, then it might make sense (although you’ll probably need to add staff elsewhere, too, if people really are that busy). If you’re trying to use the position to resolve competiting priorities where there isn’t universal agreement on what the right thing to do for the enterprise is, a new position may not resolve it.