The answer to that question depends on how agility is measured. If agility is measured in the delivery of user stories then the answer is yes. If a team is very good at an agile process yet the underlying architecture prohibits the types of changes the business really needs and wants, then the answer is no. I think agility should be measured in a team’s ability to meet business demand. Delivering quickly is one thing, being able to change at the speed of business is another. Don’t get me wrong, I am a fan of agile and agile-like methodologies, but I am a bigger fan of giving product owners and customers what they want. If an architecture is too rigid to change and/or adapt to the marketplace it diminishes the value of the user stories delivered, regardless if they were delivered quickly or not.
A few years back I posted a presentation on Slideshare called Agile Architecture. An agile architecture is one that is configurable, adaptable, and easy to integrate to and with. The goal of an agile architecture is to anticipate change, provide self service capabilities, and provide levels of abstraction so changes can be done in isolation without impacting the overall architecture.
Today I want to discuss agile architectures in the context of cloud computing, specifically SaaS (software as a service). Back in the day companies built and delivered packaged software. These products were fairly static and had long release cycles. A typical release was annual or biannual with occasional patches. These infrequent release cycles were acceptable because the customer would have to perform the updates once they received the software. In today’s world of SaaS where the customer simply uses the service and does not have to manage the software, the expectation is different. As with any web based software, we now expect frequent software updates whether they are bug fixes or feature enhancements. Consumers are used to the social web where everything seamlessly connects to each other. How many apps can you connect to simply by using your Facebook login? Consumers expect this ease of use which means SaaS products and services must connect to popular services seamlessly. To meet this expectation, an architecture must be agile and adaptable.
Characteristics of an agile architecture
An agile architecture is one that can be changed quickly to meet the demands of the market. Agile architectures anticipate change by leveraging some or all of these tactics:
- Open – Leverage APIs, connectors, feeds, etc. based on standards (you never know who/what you may be integrating with)
- Configurable – Change metadata, business rules, business processes as opposed to changing code all of the time
- Modular – Overall system is composed of many parts that can be turned on or off per customer’s needs
- Independent – Individual modules can run anywhere and can continue run when other modules break
- Elastic – Modules can scale up or down independent of one another
- Abstract – services are loosely coupled and are not constrained by other layers of the architecture (UI, database, etc)
Architectures must be agile internally as well
Even if an architecture is open and agile for consumption of external services, if it is rigid internally it can cause great pain. Module and client independence is a key concept. No two customers think alike. When your customers are large companies, they have complex systems that have unique requirements that can make integration a challenge. These unique requirements can make customer on-boarding and SLA management challenging and time consuming. Under the covers, automation and support tooling are critical building blocks for agility. Without it, IT resources will get sucked into a never ending maintenance cycle that diverts precious resources away from the next sprint. An architecture built with the characteristics I described above allows a company to connect to various tools for monitoring, SLA management, logging, forecasting, and many others. These are tools you typically don’t want to build yourself because they are not your core competency. Don’t forget your internal customers when building SaaS solutions. Quality and customer satisfaction rely heavily on empowering the support teams with tools to do their jobs.
Conceptual view of an agile architecture
This conceptual architecture of a fictitious online e-commerce site depicts one way an agile architecture can be constructed. Every image within each layer represents a service or component that is totally autonomous. Each service is designed based on the following guiding principles:
- Services/modules may be consumed internally and/or externally
- Services/modules should be technology stack and protocol agnostic
- Each service/module should not care if any of the other services/modules exist
- Each service/module should be able to scale independently
- Each service/module should be configurable via metadata
- Each service/module can be tested and deployed independently
- Each service/module should be treated as a product
The last point is critical. In some cases it makes sense to do this at an API level in others at a module level depending on the business model. Regardless, if we think about individual pieces of the architecture as independent products it forces us to think about abstraction, openness, independence, scale, and all of those characteristics I mentioned at the beginning of this post. It also allows us to make changes to individual pieces of the architecture without having to change all layers of the architecture. If we implement the layers of an architecture like in the picture above, we can often meet the business requests by changing metadata, business rules, business process, and/or through maintenance user interfaces as opposed to writing code. The more we can change through configuring and through self-service the more agile we become.
Agile Architecture Example of Agility
Here are some sample user stories to show how an agile architecture accelerates business requests. In the real world, the user stories would obviously have more detail but you get the point.
User story 1
As an order fulfillment manager, I want to add Acme Fulfillment and ABC Fulfillment to our fulfillment partner program.
User story 2
As an order fulfillment manager, I want the order system to evaluate fulfillment partners for each order and chose the fulfillment partner based on the following algorithm:
- Inventory in stock
- Proximity to ship to address
- Cost to company
- Cost to shopper
- Fulfillment partner rating
Non-Agile Architecture solution
In a traditional n-tier and tightly coupled architecture, the user stories would be broken down from these epic stories into a number of granular stories. Architects would then identify all of the code changes required by the various UIs, databases, reports, security modules and so on. A series of sprints would be established and a schedule set to make all of the code changes required to deliver these two use cases. Once the all of the code is in place, a very rigid testing cycle must be performed because the entire architecture was impacted and changed. The deployment is also a huge event because a large percentage of the code needs to be promoted and deployed. On deployment day a big bang deployment takes place. We may choose to hold deploying other business requests because too much change in one release makes it hard to troubleshoot if something goes wrong. In this case, the architecture is preventing us from being agile because it takes too long to deliver simple requests.
Agile Architecture solution
With an architecture like the one depicted above, IT can deliver these user stories much quicker. In fact, the second user story could be delivered without writing a line of code and can be promoted to production before integrating the first user story. Here is how. We update the existing work flow for fulfillment and add the decision step to evaluate the fulfillment centers. We add rules for calculating the costs. Assuming we have services or attributes for computing the proximity or rating we simply leverage those service calls by calling them from the fulfillment decision process. We test these changes in our QA environment. We run some regression and performance tests. All looks good. Now we simply promote the metadata that makes up the rules and the processes, no code changes!
For user story 1, we simply integrate with the two new vendors by exchanging our input and output APIs. We may have a standard set of APIs that the vendor must write to or we may have to write to the vendors’ APIs. Once the integration work is done, the processes and rules that we implemented from user story 2 simply work without changes. The only difference is that two new fulfillment partners enter the evaluation but the rest just works as normal.
If our reports and UIs are also built with the same level of abstraction, these two new fulfillment vendors simply appear in drop downs, filters, dashboards, etc. There should be no changes required unless specifically requested by the product team. This is agile!
User Story 3
As a marketing director, I want to push marketing messages to our enrolled shoppers on Pinterest.
Agile Architecture solution
I’ll skip the non-agile solution because you know that we will have to touch every part of the architecture. In an agile architecture we can complete this user story quickly. In fact, if we have a template layer as described in my diagram above and a social media connector service, we can complete this request in a day without any code! We simply configure our social media connector to enable Pintetest to be used, our graphics designer creates a new template specifically for Pinterest, we create an XML template for our API to output XML tags for the Pinterest template and we are done. Now when our marketing team goes into our app to run a campaign, Pinterest is available as an option and the templates can be used to tailor the message. This entire user story was done via configuration and without code. That is agile.
Agile architectures can give a company a competitive advantage by enabling IT to change at the speed of business. The ease of change comes with a large investment up front in architecture. Creating an agile architecture is not easy. As my colleague Jason Bloomberg of Zapthink once said, “Making things easy is hard”. By hard I mean it takes vision, discipline, talent, and governance. Those are four things that many IT shops are not famous for. It all comes down to the desire to achieve the ultimate agility and a culture that accepts this way of thinking. If you have both, your competition is in trouble!