Let My Process Go: Avoiding death by enterprise architecture
The other day, I wrote about the fine line between being agile and being a doormat. There is, of course, a flip-side to that equation: there’s a fine line between having a sustainable process and having no pulse whatsoever.
Way back in the early double-aughts, many pundits joyously declared that “Internet time” had killed the old-school waterfall methodology (also known as the “water torture methodology”) of software development, and that the needs of the post Millenium-Bug enterprise would drive everyone toward a world of “release early and often”. The bad old days of having multi-million dollar data warehouse projects collapse when it was discovered that the requirements had changed six months into the dev cycle were declared over, and all these great new modern development tools were just going to make code fly out the door and deploy itself.
Well, reports of the death of the waterfall methodology have been greatly exaggerated.
SD Times reports that agile software development methodologies are only now finally getting traction. According to a Forrester survey cited in the story, 14 percent of enterprises (and I’d like to see how they defined “enterprises” here) in the US and Europe have adopted agile methodologies, while another 19 percent are getting around to it.
I guess developers in that 19 percent have to clear their current dev queues first before they have time to change methodologies. And as for everyone else…I’m guessing they aren’t in any rush to give up the power that their well-documented process the gives them to control the rate of change at their companies–which can probably be described as “glacial.”
That’s because a lot of organizations have re-invented the waterfall methodology as an “enterprise architecture process”. With the goal of creating a manageable, unified IT architecture–and controlling costs–they’ve created a new additional structure that application projects have to pass through to be vetted before they can even see prototype. The results are the same as the old waterfall methodology — requirements gathering and other supporting documents consume most of the up-front time, and regardless of how interactive the process is with the users on the back-end, agility gets crushed under the weight of the process.
The results are predictable–they’re the same as what happened when client-server computing was born. Instead of getting included in the business process, the enterprise architecture process becomes something that business managers try to circumvent through skunkworks projects of their own, or solutions hobbled together from existing assets, or outright outsourcing of the whole thing. And that results in crapware, which defeats the whole point of having an enterprise architecture in the first place.
Maybe that’s why Borland and others see such a huge potential market in life cycle management and change management tools–because there are so many companies struggling to drag themselves out from under their
application life cycles. Somehow, people hope that they can automate themselves out of crapware hell by tracking things better. But that is, as my sixth grader would say, “stinkin’ thinkin’.” Measuring crap just tells you how much crap you have.
The key is uncoupling tactical business requirements from strategic architecture. We’ve been through this routine before, with n-tier client server; there’s nothing new about this architectural approach other than what protocol it’s riding over.
Service-oriented architectures partially fix the problem. By turning new application projects into “mashups” of services, you can focus on architecture where it matters–on the back end–and decentralize the process for building the presentation logic. That leaves you free to be innovative and agile on the side where it matters the most.
Sure, there’s a place for LCM tools: on the services side. With so much variation in the implementation of web services standards, you need LCM tools to keep track of what WS-whatever versioning you’ve got available. You’ve also got to track usage of services and be sure that changes you make won’t break any of those decentralized front-ends (at least not without ample warning).