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


 
 

Agile Architecture: Creating an “Anti-Framework”

Posted by Jason Bloomberg on Jun 9, 2014

I’ve been talking about my Agile Architecture approach for a few years now, both in my book, The Agile Architecture Revolution, and in blogs like this one. Now that I’m at Intellyx, it’s time to give this approach a name – so Bloomberg Agile Architecture it is.

But what is Bloomberg Agile Architecture (BAA)? True, it’s an approach, but that word doesn’t really tell you what it is. In fact, BAA is in essence a style of Enterprise Architecture (EA), in that it crystallizes a particular approach for implementing EA. So, should we call it a style the way SOA is (or should be) a style of EA or the way REST is a style of software architecture? Possibly, but BAA is more than that, because it goes well beyond the architectural constraints that define an architectural style, in that it doesn’t only include what you should do, but how you should do it.

Perhaps BAA is an architecture framework. Yet while BAA shares some characteristics in common with architectural frameworks like The Open Group Architecture Framework (TOGAF) or the Scaled Architecture Framework (SAFe), I’ve taken a different approach. The creators of these frameworks have taken a subtractive approach: in order to achieve a broad level of applicability, they have included many different options within their respective frameworks. Therefore, in order to make use of such a framework, the practitioner must pick and choose the elements of the framework that apply to their situation. Select the wrong elements for your problem area, or err on the side of caution and seek to implement too much of the framework at once, and your architecture initiative is likely to fail.



If you’ve been following my writing, you would have been quite surprised if I had called BAA a framework, given my rather lukewarm opinion on frameworks in general, dating back to 2010. Yes, one problem with frameworks like TOGAF is that they provide more content than you need, requiring the practitioner to carve out the bits that apply to them before figuring out how to take inherently general advice and make it specific. But an even more fundamental issue with frameworks is that they don’t deal well enough with change. Since we’re tackling agility head on, we need to rethink the notion of a framework.

In contrast to the subtractive approach of TOGAF and SAFe, BAA provides an additive approach: the goal is to provide a clear, implementable path to agility – but to follow BAA effectively, I would expect you to augment it with additional practices, technologies, and approaches in order to fully realize a complete architecture. Those additional elements may come from TOGAF or SAFe or other architectural frameworks, and furthermore, the practitioner must also add technology-centric practices from Cloud Computing, Big Data, SOA, or other approaches, depending upon the problem area. Thus, BAA is not meant to replace or supersede any architectural framework or technology best practice, but rather provide a single path through the noise of multiple frameworks and technologies to achieving the business agility goal.

BAA is also not a methodology. The word methodology implies a recipe of sorts, a step-by-step method for accomplishing a goal. However, BAA works at a different level: it focuses more on how to think about achieving the business goals, or in other words, the skills the practitioner needs in order to achieve business agility in their organization.

So where does this discussion leave us? I’ve decided to refer to BAA as a technique, since the focus is not on various tools or artifacts, but on how to use them. The word technique not only means how to do something, but also implies how to do something well. Just as you can improve your technique at the piano, I help architects improve their architecture technique.

With great fanfare, therefore, I hereby introduce the Bloomberg Agile Architecture Technique. Fundamentally, the BAA Technique offers a way of thinking about and doing architecture that is laser-focused on business agility as the fundamental business driver. If you’re using TOGAF or SAFe or Zachman or any number of other architectural frameworks or methodologies, the BAA Technique doesn’t require you to throw them out. Rather, the BAA Technique simplifies your choices, as it lays out a particular path through all the options facing the architect that leads to greater business agility. Contact me for more information.

TAGS:

SOA, Cloud, agile practices, agile methodologies, big data architecture


Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap