Modeling the Agile Enterprise

Nifty title isn’t it. It also happens to be the title of the Mendix whitepaper, but I just thought it would work well for this post about, well, modeling the agile enterprise. In other words, let’s talk about bringing agile development to organizations of different sizes, and the enterprise effects (…er, business agility) of IT agility.

An Example in Telecom

So there’s a great case study by Ian Evans called Agile Delivery at British Telecom. He writes about the issues involved in bringing a large company, drowning itself in the waterfall approach, to the agile age. Eight thousand IT professionals relied almost entirely on waterfall delivery, with the exception of a few “fairly small, self-contained development teams.” Commercial Off-The-Shelf systems, changing the waterfall mindset of this IT regime, an “IT department that is not highly regarded within the business,” and legacy code for which tests do not exist – make up several of the challenges that large organizations undertake.

The Size of the Enterprise

Evans offers a few reflections for CIO’s in big business… It’s important to have a ‘critical mass’ of people who will back the idea of going agile, and the applications that going agile produce. Moving from twelve month development cycles to ninety day cycles will always be faced with some opposition, but back in 2006 (when the case originated), I bet there was more opposition than there is now. My favorite reflection: “You might expect that the business would be excited at the prospect of having regular deliveries of valuable functionality. However, the business also needs to move away from traditional waterfall practices and change how it engages with the IT organization.”

SMB’s have it relatively easier than large organizations adopting agile practices. They are used to more collaboration with their IT department. In my opinion, collaboration is the future of great software. The idea that the business people who use the software should have a steady and constant say in what the developer is building seems logical, right?

Agile Methods using Visual Models

Now back to my entirely unoriginal yet perfectly suitable title – Modeling the Agile Enterprise.

“Wouldn’t it be great if I could automatically translate business requirements into working functionality, without having to explain to someone who doesn’t know my business like I do?”

This question represents a fundamental concept of adopting agile development methodologies. Business requirements, in the waterfall approach, are of highest priority at, and only at, the beginning of the development cycle. The requirements of the application are made in conjunction with business users that will then fall out of the equation until testing and production time rolls around, many moons later.

Agile development, the number one doctor prescribed way to increase business agility, takes these business users and gets them involved. First comes modeling, that’s where our business users and IT gurus sit down and use visual models to represent the processes, use cases, and logic that are needed of the application. Now, modeling the agile enterprise involves applying this concept to the organization as a whole; a much recommended and future proof goal of any organization, especially at times of unpredictability. Visual modeling is the language of both business and IT, making it all the more capable of churning out 100% requirement-satisfying applications. Each iteration of a project involves going back to these business people and making sure that the project is on track, cleaning up or adding any new requirements, while ensuring that every single one is met.

Agile for the Future

We started with the trials and tribulations of British Telecom taking on more than a development methodology, but an enterprise philosophy, that has allowed it to increase the overall productivity of its IT department, while improving business processes simultaneously. We then saw that increased collaboration between business and IT permits companies of all sizes, whether comfortable with it or not, to translate agile IT practices into strategic business practices. And let’s not forget the common language between business and IT, visual models, which crack this veritable keg of opportunity. Finally, the idea behind business agility: the ability to be flexible and adaptable enough to change with change, rather than react to change. I leave you with a quote by Charles Darwin, “It’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change.”

  • http://www.theenterprisearchitect.eu Johan den Haan

    You focus on visual models as the key to reach business agility. I partly agree with you. Visual models are an enabler to let business and IT people collaborate. The main factor to business agility in my opinion is to provide short / fast feedback cycles, i.e. it should be very fast to go from idea to working application. Again and again. Only then the IT is agile enough to enable true business agility.

    To reach these short / fast feedback cycles we need to automate the steps in these cycles as much as possible. This means using Model-Driven Development and Model-Execution-as-a-Service.