Betsy Silver, Business Development Director at RDA comments on a recent article from InfoWorld - "Interesting post about how “agile architecture” is the new way of developing solutions that can quickly and easily be modified as your business evolves."
Technology development comes in waves. Judging by the recent slippage in venture capital investment, the most recent wave of new enterprise tech has crested and is now tapering off. And it's leaving a wealth of useful new stuff in its wake, from containers to NoSQL databases to streaming analytics to machine learning APIs.
The most striking thing is not just the quantity of innovation, but how interrelated so many of those new technologies have turned out to be. Put them together and you have the makings of the new enterprise architecture, built on these four principles:
1. Self-service: In today’s enterprise, lines of business must be able to build what they need quickly without having to file requests in triplicate to a central IT bureaucracy. Either IT provides the automation necessary to deliver self-service internally, or stakeholders look outside the organization to get what they need.
2. Scalability: The abstraction of hardware as software-defined compute, storage, and network resources -- call it “the cloud” if you like -- enables capacity to be applied where it’s needed almost instantaneously. It establishes an all-purpose platform for a multitude of new applications that can scale on a dime.
3. Service-based development: Big, monolithic applications can be broken down into API-accessible microservices, each independently scalable and updatable. With microservices, applications can be built or changed much faster than before -- and developers can easily incorporate external services when needed.
4. Continuous change: Internet-based applications redefine the nature of software, so that enhancements and additions can be applied on an ongoing basis rather than frozen in periodic releases. Constant monitoring of applications and how customers use them provides the guidance for rolling improvements.
So what sort of architecture does this all add up to? The consultancy ThoughtWorks (home to Martin Fowler of Agile Manifesto fame) calls it “evolutionary architecture” -- a phrase coined by ThoughtWorks CTO Rebecca Parsons. Recently I spoke with Mike Mason, head of technology at ThoughtWorks, who offered this insight:
Evolutionary architecture is really about how you do agile software architecture. It’s about how do you do enough enterprise architecture that you are being responsible, yet you are embracing the fact that you need to incorporate new technologies and new decisions as you go and that you will learn about the stuff that you’re building over time.
In digital businesses, the classic, top-down approach to enterprise architecture, with its vast flowcharts mapping business processes with their associated technologies, becomes a straightjacket. Evolutionary architecture, by contrast, provides a framework for continuous change, where stakeholders can build what they need without stepping on each other or making poor decisions. Microservices can play a central role in that framework, says Mason:
I think that microservices are quite compatible with evolutionary architecture. I have a colleague at ThoughtWorks who actually described microservices as the first cloud-native architecture, because one of the things about microservices is that if they’re micro enough you can throw one away and start again. That’s radical thinking: “Oh my God, we’d throw away a piece of software? Why would we do that?”
The main reason, of course, is that you need to continually replace old, subpar functionality with better stuff to attract and retain customers. And as long as the API to that microservice is backward-compatible, you can develop a new microservice (using any language or framework you like) and swap it in without disruption.
In the process, you may not need to do much coding at all. If external services have the functionality you need, you can ping them instead of building your own. Plus, we live in the GitHub era, so if you need a new microservice you’re likely to find open source code for it in a repo somewhere. Microservices, like today’s physical servers, are disposable commodities rather than precious assets.
We still face technology challenges on this new frontier. Docker containers may be ideal for microservices, for example, but container orchestration and management solutions like Kubernetes and Mesos are still evolving. We also need better tools for logging, monitoring, testing, and debugging decentralized, loosely coupled applications.
Those solutions will come in time, perhaps sooner than we think. But we’re lucky to live in an era when, by accident or design, a surprisingly coherent collection of new technology has already arrived to transform the enterprise.