Todd Biske: Outside the Box

A challenge for virtually any position with “Enterprise” in the title, but especially so with Enterprise Architecture, is to continually show that they are adding value to the organization. Why? Because typically enterprise architects are not directly associated with delivery. In most IT organizations, things get delivered through projects, and enterprise architects don’t typically play the role of project architect. At best, there is an indirect association with delivery.

First off, the organization must understand that there is a need in the organization for non-project activities. It’s funny how there’s plenty of positions outside of IT that have indirect relationships to business delivery, so it’s still a bit surprising that there is still resistance toward Enterprise Architecture in many organizations. This post isn’t about how to convince management of the need for Enterprise Architecture, though. It’s about the two paths that you can go once you have that management support.

The first path is all about enforcement. Someone in senior management is upset about the decisions that are being made on projects, and as a result, they put a police force in place to review project activities. That police force is Enterprise Architecture. A personal pet peeve of mine is when the police force is put in place, but the laws are not. When that happens, project teams are at the mercy of the individual that is reviewing the project and whatever their personal interests are. Those personal interests may have nothing to do with what senior management wants, or what the project team is tasked to do. If you’re going to put a police force in place, you first need to have laws. Anyway, the point of this is that a police force approach can result in a lot of animosity. On the plus side, Enterprise Architecture does get visibility into all projects with the power to influence their direction. Also, sometime it is necessary to put a police force with a very big stick in place to force some change on an organization, but it does so at the expense of corporate culture and can result in a lot of ill will.

How do you avoid this? By remembering that as an enterprise architect, your role is not to audit, but to assist. Everything you do should be done with the thinking that your are helping to deliver, helping people to make good decisions, and helping to make their job easier, not more difficult. If you take this approach, you may still have to review projects, but your focus should be much more on communication, education, and evangelism. If you are setting standards, you should be communicating the standards, the justification for them, and the expected results to see when they are followed. If those results aren’t achieved, you should be working with the teams to understand why and get them back on the right path. Another pet peeve of mine is when someone says, “No, you can’t do that” but fails to follow up with instructions on what the right way is.

In short, if you are in a role that is normally not assigned to project teams, you must remember that you are still part of the delivery team, and everything you do should contribute to the successful delivery of a solution that meets the goals of the project and the goals of the business. It’s about being helpful, not a hinderance.

4 Responses to “Enterprise Architecture Must Assist Delivery”