Service Oriented and Agile...

I think that when Agile came along there were many people in software that didn't understand dependency management and software engineering.  I believe this encouraged architecture and design to be thrown out "with the Agile bath water."

Agile started during the DotCom boom and picked up momentum in the mid-2000s.  This was during a time when developers began to move away from strongly typed languages and at the same time the development environments and framework started to automate away a lot of the drudgery.

Dynamic languages and automation meant that you could create a prototype quality application much faster than ever before. It also gave the impression that you were engineering a solution when you were essentially hacking. I consider myself a pretty damned good coder and I know I hacked a mountain of code together in the last 20 years.  At some level having anything - even a hack - is better than having nothing.

But this surge in productivity comes at a cost.  The solutions don't scale and maintenance suffers. Worse yet, maintenance often suffers before version 1.0 can even be released. I've seen more than one project approved because of a crafty "proof-of-concept" only to bog down in the long slog to get version 1.0 into production.

On the construction side we traded quality and modularity for hack-ability and funding.

On the process side we experienced an equally dangerous "devil's bargain." We traded architecture, project management, and service orientation for User Stories and a client facing backlog.

I don't believe this was a fair trade. The successful companies build services and find a way to do project management and engineering despite the heavy hand of Agile.

Have you ever noticed that there is a high coloration between being service oriented and successful software? The better a piece of software, the higher that chance it will have a service oriented API. APIs are only possible when the designers have thought through the required services and designed the architecture.  And clearly the most successful way to build software is as a set of services.

Assuming you agree with those claims, have you ever noticed how little talk there is among Agilist about services and service oriented architecture?

So here we have what is clearly - demonstratively - the most successful way to build software and the most popular methodology says nothing about it and does not encourage discovering and building services. In fact, it arguably discourages service oriented architecture. 

We need to rethink Agile, keep the good, and reintroduce dependency based project management, software engineering, and service oriented design.

These are the new and exciting practices.  Agile has starting to feel old, stale, and ineffective.