In preparing for battle I have always found that plans are useless, but planning is indispensable.
Dwight D. Eisenhower

Some time ago, I was on the circuit talking about Service Oriented Architecture and a roadmap for moving forward. Since then, we have had many false starts and hit many snags along the path. There is slow movement: we are standing up an ESB for testing, we have started a project to expose Course Roster data as an enterprise service, and groups are moving towards Web Services as there preferred integration technology. This is still a long way away from from SOA as an enterprise architecture.

The snags:

First – Our projects and budgets are run in isolated silos. Each project is completely focused to deliver a narrow scope of functionality. The broader ideas of enterprise fit, building the core of the enterprise and advancing the strategic plan are only oblique influences at best. Budgets are also narrowly focused and isolated. Our ability to fund general infrastructure improvements is greatly limited by the narrow focus of our projects and our budgets.

Second – We have a strong “wait for the vendors” effect. Vendor X said they would deliver it in 2011. “Why start until we see what they have?”

Third – There is a lack of “acting for the enterprise as a whole”. Various business units view themselves as isolated enterprises. They run independently and don’t really see a need to act in collaboration for the whole of institution. Any attempt to bring in the larger view is seen as scope creep, as slowing them down or as adding costs that they didn’t plan on.

These three things are not criticism of the project sponsors, departments or other groups. They are the reality of the environment in which they operate. A good project manager tries to limit the scope of the project to ensure success. A good service manager focuses on delivering the services their customers requests as efficiently as possible. A good budget officer works to stretch the budget as far as possible and to keep expenditures focused on the group’s goals and mission.

The realizations:

I recently read, Enterprise Architecture as Strategy by Ross, Weill and Roberston (Harvard Business School Press). I came to understand that we had not done the early work needed to successfully migrate to SOA. There were three critical steps that we skipped. Missing these steps meant that our move to SOA wasn’t well understood, wasn’t accepted as a the strategy and individual groups didn’t understand their role in the migration process.

In Enterprise Architecture as Strategy, the authors talk about the hard work that has to occur to set an over-arching Enterprise Architecture. That work involves getting the various business leaders together and having them: understand the options, decide on a fundamental architecture and then create a model of the “core functions” for the enterprise.

The two axes that define the over-arching Enterprise Architecture are the levels of data integration and the level of common business processes. In other-words: how much data do we share and similarly do we do things. Once that is decided, then the business leaders work on describing those things that make up the core of the business. The business leaders say which data elements are important to share and which business processes are best to standardize.

This model of the core elements for the enterprise are a good foundation for the Service Oriented Architecture. Looking at this model, you quickly understand those things which should be represented as services and those processes which should orchestrated across the enterprise.

Most importantly, the business leaders – those who will run the projects, spend the budgets and provide the services, have agreed that these things should be shared. They see the value of the taking on the extra expense and work of migrating to SOA. They will hopefully agree to build out the needed infrastructure.

In essence, they have seen the future state and have agreed to work towards that state. By looking at the core elements document, they can see which elements are theirs to provide and which elements they will get to leverage to improve their own service.

We are just starting this conversation on campus in a couple of different forums. The fact that we started the migration to SOA without having this conversation meant that SOA was an abstract burden to many groups and projects rather than a tool help those groups and projects attain a desired and agreed upon future state.

The New Strategy

First – it is important to have the Enterprise Architecture as Strategy discussions. The challenge will be determining the correct decision makers to include in the discussion and to get them to understand the process. A decision that something is Unified (that it has a common business process and shared data) does not mean that it is all done centrally. Nor does it mean that there isn’t local control.

Second – core infrastructure needs to be moved into a core budget and out of individual project or group budgets – at least as much as possible. This is a long-haul effort that will require years of work. Fortunately, I think our CIO and our campus see the value in this discussion and in the changes needed to revamp the budget.

Third – we need to find places to make small advances to demonstrate value and to move projects along. We need to take the “if we build it, they will come more willingly” approach . If we can get parts of the infrastructure in place, then projects will adopt it more readily. If we can build a few key services, then new requests can be filled more quickly by utilizing these services than by building another one-off solution.

The Advances we’ve made

We are currently standing up an Enterprise Service Bus. This will be a first step part of the infrastructure. It will allow our technologists to learn about the technology and will provide a backbone for future development.

We have also started a project with campus to work on a common interface for Course Roster like data. This will be a good first enterprise service to expose along the service bus.

Finally – there is a broad effort starting to rationalize and unify some of the administrative business processes on campus. This could be a forum for the beginnings of the EA as S discussions. This effort actually came out of the Departments and Dean’s offices. The need was identified by these groups as a response to the pain they see coming with 6 ERP implementations coming their way. The fact that the effort was started by Department Chairs and Deans means they are open to changes and discussions of new ways and new processes. The fact that there are several new ERPs coming along means that we can use disruption to our advantage.