Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


 
 

The Agile Architecture Mind Map

Posted by Jason Bloomberg on May 8, 2014

It seems that most people who read the title of my book The Agile Architecture Revolution think I’m talking about Agile software architecture. In reality, I’m talking about architecting for business agility – a technology-enabled approach to Enterprise Architecture (EA) focused on enabling the enterprise to be more agile. But I can understand their confusion. In fact, I welcome it.

The reason I welcome the confusion between the style of EA I call Agile Architecture (AA) and the perhaps more familiar use of the phrase to represent the software architecture required for Agile development projects is because these two meanings are interrelated. In fact, AA is inherently software-based, and furthermore, extending the Agile principles from the Agile Manifesto across all conceptual levels of the enterprise (organizational, process, technology, and information, for example) is an integral part of the AA vision.

There is more to the AA story, however. So, to connect the dots, I put together the following mind map:



The Agile Architecture Mind Map

The Agile Architecture Mind Map

At the center of the mind map, of course, is AA, which connects to four main concepts: Business Agility, Enterprise Architecture, Agile Technology / Innovation, and Software Architecture. Note that the Agile manifesto hangs off of the latter, implying the world of Agile software development is tagging along for the ride.

The business motivation for the entire map, however, is Business Agility. I’ve long defined Business Agility as the ability for an organization to respond to change and leverage change for competitive advantage. In this map I break out the two parts of this definition. First, responding to change, both in the form of responsiveness (responding to positive change) and resilience (bouncing back from adverse change). Second, the ability to innovate: the strategic benefit of agility, where an organization introduces change into the business environment intentionally in order to gain a strategic advantage in their marketplace.

EA sits by itself on the right, but make no mistake: EA is no dead end here. Rather, EA informs and guides the entire chart. Imagine if you will, therefore, dotted lines from EA to everything else. You’re now picturing a mess, which is why I didn’t draw the chart that way. But the principle that EA connects to everything else remains.

Finally, we have Agile Technology hanging off the bottom of AA, in turn connecting to several hot buzzwords du jour. But fear not, my selection of DevOps, Cloud Computing, Big Data, and Next-Gen SOA had nothing to do with how hot these terms are today. Rather, the common thread across these approaches is automation.

Take DevOps, for example. DevOps is an organizational model that shifts the role of the operations staff so they work hand-in-hand with developers – and this reorganization is possible because their organizations are automating the operational environment, typically via Cloud Computing. Cloud Computing also drives the automation of Big Data analytics platforms and technologies. The automation of increasingly sophisticated levels of operational technology drives reorganization, first in IT and then across the entire organization. Architected properly, this reorganization leads to greater business agility.

Finally, we come to the Next-Gen SOA box – “next generation” in the sense of lightweight, Cloud-friendly, REST-based, and decentralized, rather than the middleware-driven, centralized, expensive, Web Services-based approach I call first generation SOA. As I’ve written about before, there are still many pieces missing to the Next-Gen SOA story, but organizations who get it to work properly are able to abstract the policy layer in order to automate governance across the application environment.

Automation, therefore, is the common theme across the technology enablers of AA. SOA governance gave us a glimpse of how such automation was supposed to drive business agility, but the architecture – and its available implementations – generally fell short. AA fills in these missing pieces, pulling together all the elements of the mind map above into a coherent, realizable story for implementing technology-enabled business agility across the enterprise. Drop me a line if you’re interested in learning more.

TAGS:

SOA, governance policies, Agile Software Development


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap