Todd Biske: Outside the Box

Archive for August, 2010

A couple of weeks ago, I asked a simple question on Twitter: Should Enterprise Architects have/get an MBA? That meme made its way to InfoQ, so I figured I should actually post my own thoughts on the subject.

First, a full disclaimer: I don’t have an MBA. I do have a MS in Computer Science from the University of Illinois (go Illini!). At the time I got my Master’s, a friend of mine took a different route and did a combined MCS (Master of Computer Science)/MBA degree. In retrospect, I wish I had taken that route. Part of my reasoning to not go that route was the whole MCS designation. Who has ever heard of that? Even from an institution like Illinois, would anyone have known what it is? For those of you wondering, it’s basically a course-only option for a Master’s degree. Getting an MS required writing a thesis. Getting an MCS did not. More importantly, however, I realize now that my interests lie more in the application of technology than in the technology itself. I had inklings of it back then, but at that time, it was far more important to be strong in technology first, rather than the domains in which it was applied.

Today, it’s a different story. There are no shortage of tech-savvy people in the business, so simply being a technology expert is not going to get you as far as it did 20 years ago. I’ve seen enough headlines that say IT departments are shrinking, meaning that some of the technology knowledge needed is being provided by people outside of IT. I don’t think this trend is going to reverse itself, so those of us that want to make a career in the application of technology will increasingly need more business-savvy.

So, should we all go back to school and get MBA’s? I view it as a tool in your toolbox. It is not a guarantee of success, but it is something that can make the path easier. Having long term career goals and a clear idea on what it will take to achieve them is probably far more important. Some companies may look highly on MBAs in making personnel decisions, others may not. Those are all factors to consider.

The other thing I wanted to comment on is the fact that many (IT) people lamented that EA isn’t part of the MBA program. I don’t agree with this at all. It’s a business degree, and like it or not, EA is still viewed as a technology discipline, not a business discipline. I do believe, however, that MBA programs should include some aspect of technology management. If an MBA prepares you to be a CEO, shouldn’t you have some idea on what your CIO and CTO should be doing?

As for me, getting an MBA is on my radar, but I haven’t yet made a decision on it. I definitely am reading more business strategy books, and for now, I think that’s the right approach for me, as frankly, I’m more concerned about paying for my kids’ education than financing continuing my own. But if I were in college today, given what I have learned about my interests in applying technology rather than building technology, I would definitely take that path, combined with a technology degree.

Yesterday afternoon, I was involved with a discussion around EA 201x. The conversation began at a lunch meeting I had with Mike Rollings (@mikerollings) of Burton Group/Gartner, and continued on with Brenda Michelson (@bmichelson) of Elemental Links and fellow EA Chris Bird (@seabird20), among others. Near the end of the conversation, Chris asked the question, “Are Enterprise Architects really Enterprise Archivists?” Brenda responded that we really need Enterprise Activists focused on action, delivery, ideation, and evangelism.

The more I thought about this, the more I love the picture that is painted by this. An archivist is essentially a librarian, and unfortunately, there are probably many EA teams that fall into this category. I’m sure there are probably many CIO’s who also think this is exactly what EA should be doing: managing the list of approved technologies, standards, etc. That is a necessary activity, but is it really what your EA team should have as its primary purpose?

Now, think about the activist. Put aside any negative connotations associated with political activists and judicial activist, and focus on the pure definition, which is someone who engages in activism. Merriam-Webster defines activism as “a doctrine or practice that emphasizes direct vigorous action especially in support of or opposition to one side of a controversial issue.” So, enterprise activism, or enterprise architecture activism, should be direct, vigorous action in support of the architecture of the enterprise. Anyone who has worked in big IT also knows that there’s no shortage of politics and tension between enterprise views versus project views, strategic views versus tactical views, so I think it fits the “controversial” term as well.

Brenda’s comments about seeing action, delivery, ideation, and evangelism hits the mark.

• Action: The action is engagement. Talk to the people that have the ability to make change happen. Using the activism analogy, the EA is the lobbyist. Engage the stakeholders, and make your case.
• Delivery: Deliver the strategic architecture, and then work with the project teams to make sure the architecture is realized properly. If you’re only cataloging what other people have done, you’re an archivist.
• Ideation: Think about the future. James McGovern (@mcgoverntheory), a fellow EA, had posted once that EA’s need to have time to think. This is where the ideas come from, and then can get turned into the strategic architecture. They’re not the exclusive source of ideas, but EA’s are supposed to be your senior level thinkers, so innovative ideas should be expected of them.
• Evangelism: How can you be an activist without being active? Make the cause known. If the cause isn’t heard, work to understand why, and tweak the message accordingly.

Just writing this up actually has cause me to think about some things that I can improve on in my own role as an Enterprise Activist. While I doubt we’ll see this as a job title anytime soon, I think it’s the right vision, can help others understand the role, and can be a powerful motivator for the team.

Jeff Scott recently posted a blog listing 14 challenges faced by business architects. They really apply to any enterprise architecture practice, and I wanted to call out and comment on a few of them.

Lack of business skills in the EA team. I commented directly on Jeff’s post on this one. I am sure there are many EA’s that have heard this statement, the problem is that it isn’t actionable. What specific skills or knowledge is missing? If you can’t get a straight answer on this, be wary of the protectionist culture that exists in many organizations. This is even expressed in another one of Jeff’s challenges, “Gatekeepers protect their business relationships.” We should all be focused on achieving the business goals, but frequently our actions are more geared toward protecting turf and climbing the corporate ladder. Someone who refuses to tell you how you can improve may be guilty of this practice, whether done with intent or simply because that’s the culture. This is why you must follow the words of another Forrester analyst, Gene Leganza, and answer the question, “What’s in it for me?” (Forrester subscription required).

An approach I like to use is to always emphasize that I’m here to help. I’m not here to be the police force and a bottleneck, I’m here to make our outcomes better. If they have people performing functions similar to enterprise architecture, but perhaps called something different, don’t turn it into a turf battle because you will lose, assuming the group is having success with it. They’re already performing the function, so unless you have a way to make that function better, there is no impetus for them to change. One thing I’ve done in those situations is to turn the conversation around and get them to start sharing their practices with other teams, and offer to be the facilitator of that communication. That can certainly play to the ego of any protectionist, but it can also be a great asset for you in demonstrating the value of the practice of architecture. Remember, it’s more important to establish the practice than it is to establish the team. Otherwise, you’re just falling into the same turf war culture that everyone else does.

Another challenge Jeff mentioned is a culture of change resistance. The scenario I described above was one where no change was needed, because the practice was being done with good results. If the results are not good, change is needed. Prior to any discussion on how to solve the problem, you have to get agreement that there is a need to change. If you get that agreement, now you can have a solid discussion. If someone doesn’t agree on the approach, ask to come up with an alternative, because you’ve already reached agreement that something needs to change.

Of the rest of the challenges, there are two others that I wanted to call out, you can review the rest on Jeff’s blog. They are: “Business units plan and work in silos” and “Tactical business focus.” These two strike at the heart of my previous post on defining the enterprise first. If the business hasn’t recognized that there are certain things that must be addressed at an enterprise level, then clearly anything with an enterprise scope will be a challenge. These are cultural issues that may be outside of EA’s ability to address, yet they are huge impediments to a successful practice. My experiences indicate that it will take someone at an executive leadership level to make this happen. They must be interacting with the directors of those silos and the common leadership above. You may be able to get some things done at a grass roots level because some individual managers may be open to shared planning, but it’s hard to turn that into systemic change without help from the top.

Thanks to Jeff for collecting these challenges, I hope others will contribute to actionable guidance that can help overcome them.