Todd Biske: Outside the Box

Archive for the ‘Open Group’ Category

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.

I was a panelist for a discussion on the Future of SOA at The Open Group Enterprise Architecture Practitioner’s Conference in late July. The session was recorded and is now available as a podcast from Dana Gardner’s BriefingsDirect page. Please feel free to followup with me on any questions you may have after listening to it.

Andres Carvallo is the CIO for Austin Energy. He was just speaking on how the Internet has changed the power industry. He brought up the point that we’ve all experienced, where we must call our local power company to tell them that the power is out. Take this in contrast to the things you can do with package delivery via the Internet, and it shows how the Internet age is changing customer expectations. While he didn’t go into this, my first reaction to this was that IT is much like the power company. It’s all too often that we only know a system is down because an end user has told us so.

This leads to discussion of something that is all too frequently overlooked, which is the management of our solutions. Visibility into what’s going on is all too often an afterthought. If you exclusively focus on outages, you’re missing the point. Yes, we do want to know when the .001% of downtime occurs. What makes things more important, however, is an understanding of what’s going on the other 99.999% of the time. It’s better to refer this as visibility rather than monitoring, because monitoring leads to narrow thinking around outages, rather than on the broader information set.

Keeping with the theme of the power industry, clearly, Austin Energy needs to deal with the varying demands of the consumers of their product. That may range from some of the major technology players in the Austin area versus your typical residential customer. Certainly, all consumers are not created equal. Think about the management infrastructure that must be in place to understand these different consumers. Do you have the same level of management in your IT solutions to understand different consumers of your services?

This is a very interesting discussion, especially given today’s context of HP’s acquisition of Opsware (InfoWorld report, commentary/analysis from Dana Gardner and Tony Baer).

Joe Hill from EDS is on the stage now. The title of his talk is on SOA and Outsourcing, although it’s far more broad than just an outsourcing discussion. It would be nice to have a copy of his slides, as he had some really good ways of visualizing SOA adoption along a timeline and the differences on how it should be approached. For example, using a chart reminiscent of Clayton Christensen’s “The Innovator’s Solution”, he showed that at the early phases where we have “performance undersupply,” the typical solution may need to be more tightly coupled, fewer vendors, and more use of proprietary techniques. The discussion around SOA is typically on the right hand side of the chart, emphasizing loose coupling, multiple vendors, open standards, etc. The problem that I felt Joe was emphasizing was that you need to recognize where you are and apply the right techniques at the right time, rather than on focusing too heavily on the end state on the right hand side of the diagram.

Rob High of IBM is on the stage now with a presentation titled “SOA Foundation” which runs the gamut of topics associated with SOA. One thing he took a lot of time to discuss was the notion of coherency and the importance of semantics to SOA. It was nice to hear some emphasis on this point, as I believe that an understanding of the semantics is a critical component in moving from SOA applied to applications to SOA applied to the enterprise. Just as with the rest of SOA, make sure you understand the semantics first before throwing any semantic technology at it. While there are evolving specs and tools in this space, none of that will do you any good if don’t first understand the semantics themselves and how that information can be leveraged in your project efforts.

I’m here at The Open Group Enterprise Architecture Practitioner’s Conference, and will try to blog where I can on the presentations. Right now, I’m sitting in David Linthicum’s keynote, which is on EA & SOA. He had an interesting quote, which was:

Five years from now, we won’t be talking about SOA… It will all be folded back into EA.

There’s some truth to this, but there’s also a lot of risk. One of the issues with EA (and many other efforts within IT), is that it can become disconnected from the project efforts that are going on. The term most frequently used with this is “ivory tower” where enterprise architects are simply viewed as paper pushers that know how to create a lot of PowerPoint slides. One of the side benefits of SOA is that it relates very well to the world of the development projects, with “service” being the point of common language. The enterprise architects may be modeling the enterprise in terms of the services that are needed, and projects can now utilize these models in their project architecture. This is easier said than done, however, as you need to ensure that the reference material containing these models (e.g. a reference architecture) is consumable at the project level. If the only group that can understand your models are fellow enterprise architects, that’s a problem.

So, will SOA be folded into EA as a whole? If EA can ensure that the artifacts it creates are consumable at the project level, then absolutely, SOA will be folded into EA. If EA is not creating artifacts that are consumable at the project level, then we have a problem. You’ll likely still have tension between EA and SOA, and likely not achieve the levels of success that organizations that have successfully bridged the world of EA and the project space. This doesn’t apply solely to SOA. This applies equally to any architectural domain. You may have information architects working on canonical or enterprise data models, performing data quality analysis, etc., but if it doesn’t find a way to become relevant to project efforts, it will exist on an island with continual struggles to achieve the objectives that were set out.