Think Enterprise First
Think enterprise first. Such a simple statement, but yet it is so difficult to do. Admittedly, I am an enterprise architect, so it’s my job to think about the enterprise. In reality, it’s not just my job. If you are an employee, it’s your job, too.
Why am I bringing this up? I believe that having a simple, clear statement that embodies the change that we’re looking for is critical for making that change occur. so, when I sat back and thought about my experiences over the years and tried to think of a general, common problem that needs to change, what became clear was the very project-centric culture of most IT organizations.
Projects are necessary to ensure that delivery occurs, but let’s face it, have you ever been on a project where scope was the least flexible thing? From day one, schedule and resources are always less flexible than scope. As a result, we have an IT culture that is obsessed with on-time, on-budget delivery, that will always sacrifice scope.
While schedule and resources will always wind up being the least flexible thing by the end of the project, it shouldn’t begin that way. The change that must occur is to start out thinking “enterprise first.” The simplest example I can think of this is in service development. What’s the behavior in your organization? Do teams build “their” application and only create services where a clear opportunity for reuse exists (or when a governance team forces them to), or do your teams define their projects as services first (regardless of any known opportunities for reuse) and then add in whatever application-specific stuff is necessary. The latter is an enterprise-first thinking, the former is an example of project-first thinking.
The argument you may have is, “isn’t this going to result in bloated , over-engineered solutions?” It shouldn’t. Making something a service doesn’t require surveying the enterprise for requirements. it means we place the proper ownership and management around that service so that it is positioned for change. We can only design to the knowledge that we have based on past experience and known requirements. We can’t predict what changes will come, we can only make sure we are properly prepared for that change. project-first thinking doesn’t do that, enterprise-first thinking does. Think enterprise first.
Well said. It really doesn’t take much extra effort to separate out the logic tier of applications such that they are services. And this helps define clear boundaries around areas that should be properly governed. It’s challenging to design your services so they are loosely coupled to each other and will survive significant changes (upgrades / replacements) in underlying systems.
[…] Todd Biske, enterprise architect extraordinaire and author of SOA […]
[…] Todd Biske, enterprise architect extraordinaire and author of SOA […]
[…] Todd Biske, enterprise architect extraordinaire and author of SOA […]