Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

Posted by Jason Bloomberg on July 18, 2014

Making up new words for old concepts – or using old words for new concepts – goes on all the time in the world of marketing, so you’d think we’d all be used to it by now. But sometimes these efforts at out-buzzing the next guy’s buzzword just end up sounding silly. Here are three of the silliest going around today.

1.       Human-to-Human, aka H2H. This one came from Bryan Kramer of PureMatter. According to Kramer, “there is no more B2B or B2C. It’s H2H: Human to Human.” In other words, H2H is the evolution of eCommerce after business-to-business and business-to-consumer. The problem? Commerce has been H2H since the Stone Age. The next generation of eCommerce is two people haggling over a fish?

2.       Business Technology. This winner comes from a recent article by Professor Robert Plant in the venerable Harvard Business Review. Dr. Plant espouses that “we should no longer be talking about ‘IT’ as a corporate entity. We should be talking about BT—business technology.” Business technology? Seriously? How long have businesses used technology? Earlier than punch card readers. Earlier even than typewriters. Perhaps blacksmiths’ tools? IT – information technology – is a worn out term perhaps, but at least we know it has something to do with information.

3.       Digital. This one is all over the place, so it’s hard to point fingers. But I will anyway: this article from MITSloan Management Review and Capgemini Consulting, for example, which defines digital transformation as “the use of new digital technologies (social media, mobile, analytics or embedded devices) to enable major business improvements (such as enhancing customer experience, streamlining operations or creating new business models).” What, pray tell, does the word digital mean? It refers to a computer that uses bits, as opposed to analog computers that use, what? Sine waves? In other words, 1940s technology.

Ironically, in spite of the digital silliness, the aforementioned article is actually quite good, and I highly recommend it. Even more ironically, I find myself describing what I do as helping organizations with their Digital Transformation initiatives. I guess if you can’t beat ‘em, you might as well join ‘em.

Posted by Jason Bloomberg on July 9, 2014

Nowhere is the poor architect’s quest for respect more difficult than on Agile development teams. Even when Agilists admit the need for architecture, they begrudgingly call for the bare minimum necessary to get the job done – what they often call the minimum viable architecture. The last thing they want are ivory tower architects, churning out reams of design artifacts for elaborate software castles in the sky, when the poor Agile team simply wants to get working software out the door quickly.

My counterpart in Agile Architecture punditry, Charlie Bess of HP, said as much in his recent column for CIO Magazine ominously entitled Is there a need for agile architecture? His conclusion: create only an architecture that is “good enough - don’t let the perfect architecture stand in the way of one that is good enough for today.”

Bess isn’t alone in this conclusion (in fact, he based it on conversations with many Agilists). But any developer who’s been around the block a few times will recognize the “good enough” mantra as a call to incur technical debt – which may or may not be a good thing, depending upon your perspective. Let’s dive into the details and see if we’re asking for trouble here, and if so, how do we get out of it.

Technical debt refers to making short-term software design compromises in the current iteration for the sake of expedience or cost savings, even though somebody will have to fix the resulting code sometime in the future. However, there’s actually two kinds of technical debt (or perhaps real vs. fake technical debt, depending on who’s talking). The “fake” or “type 1” technical debt essentially refers to sloppy design and bad coding. Yes, in many cases bad code is cheaper and faster to produce than good code, and yes, somebody will probably have to clean up the mess later. But generally speaking, the cost of cleaning up bad code outweighs any short-term benefits of slinging it in the first place – so this sloppy type of technical debt is almost always frowned upon.

In contrast, type 2 (or “real”) technical debt refers to intentionally designed shortcuts that lead to working code short-term, but will require refactoring in a future iteration. The early code isn’t sloppy as in type 1, but rather has an intentional lack of functionality or an intentional design simplification in order to achieve the goals of the current iteration in such a way that facilitates future refactoring. The key point here is that well-planned type 2 technical debt is a good thing, and in fact, is an essential part of proper Agile software design.

The core technical debt challenges for Agile teams, therefore, are making sure (a) any technical debt is type 2 (no excuses for bad code!) and (b) that the technical debt incurred is well-planned. So, what does it mean for technical debt to be well-planned? Let’s take a look at the origin of the “debt” metaphor. Sometimes borrowing money is a good thing. If you want to buy a house, taking out a 30-year mortgage at 4% is likely a good idea. Your monthly payments should be manageable, your interest may be tax deductible, and if you’re lucky, the house will go up in value. Such debt is well-planned. Let’s say instead your loser of a brother buys a house, but borrows the money from a loan shark at 10% per week. The penalty for late payment? Broken legs. We can all agree your brother didn’t plan his debt very well.

Just so with technical debt. Over time the issues that result from code shortcuts start to compound, just as interest does – and the refactoring effort required to address those issues is always more than it would have taken to create the code “right” in the first place. But I put “right” in quotes because the notion that you can fully and completely gather and understand the requirements for a software project before you begin coding, and thus code it “right” the first time is the fallacy of the waterfall approach that Agile was invented to solve. In other words, we don’t want to make the mistake of assuming the code can be complete and shortcut-free in early iterations, so we must plan carefully for technical debt in order to deliver better software overall – a fundamental Agile principle.

So, where does this discussion leave Bess’s exhortation that you should only create architecture that is just good enough? The problem: “just good enough” architecture is sloppy architecture. It’s inherently and intentionally short-sighted, which means that we’re avoiding any planning of architectural debt because we erroneously think that makes us “Agile.” But in reality, the planning part of “well-planned technical debt” is a part of your architecture that goes beyond “just good enough,” and leaving it out actually makes us less Agile.

Bloomberg Agile Architecture™ (BAA) has a straightforward answer to this problem, as core Agile Architecture activities happen at the “meta” level, above the software architecture level. By meta we mean the concept applied to itself, like processes for creating processes, methodologies for creating methodologies, and in this case, an architecture for creating architectures – what we call a meta-architecture. When we work at the meta level, we’re not thinking about the things themselves – we’re thinking about how those things change. The fundamental reason to work at the meta level is to deal with change directly as part of the architecture.

In order to adequately plan for architecture technical debt on an Agile development project, then, we must create a meta-architecture that outlines the various phases our architecture must go through as we work our way through the various iterations of our project. The first iteration’s architecture can thus be “just enough” for that iteration, but doesn’t stand alone as the architecture for the entire project, as the meta-architecture provides sufficient design parameters for iterative improvements to the architecture.

However, it’s easier said than done to get this meta-architecture right. In fact, there are two primary pitfalls here that Agilists are likely to fall into. First, they may incorrectly assume the meta-architecture is really just a part of the architecture and thus conclude that any effort put into the meta-architecture should be avoided, as it would be more than “just enough” and would thus constitute an example of overdesign. The second pitfall is to assume the activities that go into creating the meta-architecture are similar to the activities that go into creating the architecture, thus confusing the two – which can lead to architecture masquerading as meta-architecture, which would actually be an instance of overdesign in reality.

In fact, working at the meta-architecture level represents a different set of tasks and challenges from software architecture, and the best choice for who should create the meta-architecture might be different people from the architects responsible for the architecture. These “meta-architects” must focus on how the stakeholders will require the software to change over time, and how to best support that change by evolving the architecture that drives the design of the software (learn to be a meta-architect in my BAA Certification course).

Such considerations, in fact, go beyond software architecture altogether, and are closer to Enterprise Architecture. In essence, when I talk about Bloomberg Agile Architecture, I’m actually talking about meta-architecture, as the point to BAA is to architect for business agility. Building software following Agile methods isn't enough. You must also implement architecture that is inherently Agile, and for that, you need meta-architecture.

Posted by Jason Bloomberg on July 7, 2014

Sometimes random thoughts in the blogosphere coalesce into a strange synergy of ideas. When this happens, my natural impulse, of course, is to blog once more. In this case, no sooner had I written my last blog post about the need for a well-architected balance between the RESTful API management headache and excessive governance, when Jim Franklin of SendGrid published this article on developer-led innovation, where rule #8 calls for setting standards for coding RESTful APIs.

Add to this confluence an article from the latest issue of Fast Company Magazine on the rise and fall of Facebook’s “Hacker Way.” The Hacker Way – move fast, break things, and code wins arguments – helped drive Facebook’s culture until it got too big for the hackers to run the show. As a result, Facebook has been learning the hard way that hacker-led innovation has its drawbacks as well as its positives.

Fair enough, but what works (or doesn’t work) at Facebook won’t necessarily play in the enterprise – and the enterprise is my focus, as well as Jim Franklin’s. So, let’s put all of these ideas in a pot and stir, and see what kind of stew we end up with.

Superficially speaking, the enterprise alternative to the Hacker Way is simply the opposite of each statement: instead of move fast, the enterprise moves slow; hackers break things while the enterprise leaves things alone because they’re fragile; and instead of code winning arguments, business stakeholders win arguments.

But there’s more to this story, as the chart below illustrates.

The Hacker Way

What They Mean

The Enterprise Alternative

The Bloomberg Agile Architecture™ Way

Move fast

Agile development focuses on short sprints. Write good code as quickly as possible to drive innovation.

Move slowly - release cycles take months

Architect software to be inherently flexible so speed is driven by business need

Break things

Continuous iteration and rapid prototyping. Code until all tests pass.

Leave legacy alone - it's too fragile and important to mess with

When abstract models drive business capabilities and the underlying software provides affordances, people can prototype rapidly without breaking anything important

Code wins arguments

Developers drive innovation. Working software trumps discussions about software capabilities or business needs.

Business stakeholders drive innovation. Business strategy trumps code.

Innovation is a team effort. Business stakeholders must understand what technology affords them, while developers must focus on providing affordances to the business


In the chart above, the second column is my interpretation of what Facebook and perhaps other people mean by the principles of the Hacker Way. The third column is the traditional enterprise alternative to those principles.

If those columns were the whole story, we’d have nothing more than an example of how hackers and enterprises don’t see eye to eye. But from my perspective, Agile Architecture brings hackers and large organizations together. Hackers want to roll out new capabilities quickly, while enterprise software moves slowly. Bloomberg Agile Architecture (BAA) calls for inherently flexible software: the underlying code can move slowly, while the resulting application functionality can be as dynamic as the business requires.

The central technique here is to separate software capabilities from affordances. The underlying platform and associated infrastructure provide affordances – in other words, it’s up to people (hackers and others) to create different things with the platform depending upon their needs or desires. Software capabilities, therefore, are shifted toward users, enabling rapid prototyping without breaking the software. “Break things” thus becomes an overly simplistic principle, as BAA allows organizations to break what they need to break as part of the innovation process without breaking the underlying stuff that you don’t want to mess with nearly as often.

BAA thus addresses the question as to whether you want your developers to drive innovation in the enterprise. Argument for: techies are more likely to understand the power of today’s technologies than the business users. Argument against: it’s the business users who better understand customers and the marketplace the enterprise competes in. Conventional wisdom: business users and techies struggle to communicate with each other, and don’t like each other much in any case.

BAA navigates a course past this impasse. Yes, business stakeholders and developers must work as a team to drive innovation. But this isn’t just an unstructured Kumbaya Moment here. Rather, developers should focus on affordances while business users should focus on capabilities. Once everybody understands the difference (and it’s really not that difficult), then we finally have a recipe for technology-supported innovation in even the stodgiest of enterprises.

Posted by Jason Bloomberg on July 3, 2014

Perhaps the most successful part of Representational State Transfer (REST) to date has been the simplification of Application Programming Interfaces (APIs). We no longer need a language-specific protocol that depends upon sophisticated network controls under the covers. Today we can take HTTP for granted, and a simple request to a URL suffices to establish any interaction we care to implement between any two pieces of software we like, regardless of language. What could be easier?

 Easy, yes, but with easy comes a dark side. If something’s easy, then anybody can do it. And if anybody can do it, then anybody will do it. And when that happens, you’re more likely to have chaos than orderly integration. And therein lie numerous, often unexpected problems.

REST, after all, is rather vague about many of the specifics of its implementation. Data formats, URI conventions, and how the hypermedia constraint is supposed to work, for example, are all subject to interpretation. As a result, many organizations have a plethora of different RESTful API styles, leading to incompatibilities, code maintenance issues, and even potential security risks.

For numerous vendors, of course, chaos means opportunity, and the API Management market is exploding as a result. You’d think as the API story shifted over the last decade from Web Services to RESTful interfaces that the core challenge would have become simpler. Au contraire: REST’s inherent flexibility has actually exacerbated the management headache, to the detriment of many IT shop’s API strategies.

The most obvious solution to the problem of easy APIs is to crack the whip. Establish rigorous, formal policies for how everyone must build their APIs, and then firmly enforce those policies. In other words, introduce governance into the development shop. Follow the rules or else!

Unfortunately, this heavy-handed approach to governance is usually counterproductive. It lowers morale and productivity among the development team, and can also limit the flexibility of the resulting software, which can adversely impact the agility of the organization.

What then is the best approach for managing the easy API problem, without falling into the traps of a management headache on the one hand or “Big Brother” governance on the other? The answer: a well-architected balance between these two extremes.

By “well architected” I mean first, that architectural decisions must be business-driven, and second, they must empower inherently flexible software – in other words, Agile Architecture. Yes, API management tools, especially when they support a dynamic API abstraction, are an important enabler of Agile Architecture. But then again, so is an automated governance approach that encourages consistency in the application of API approaches while allowing flexibility. Bloomberg Agile Architecture strikes this balance. Learn more in an upcoming Bloomberg Agile Architecture Certification course.

Posted by Jason Bloomberg on July 1, 2014

At Intellyx we break down business agility into three core business drivers: responsiveness, resilience, and innovativeness. This perspective on business agility, however, is not universal. In fact, most people separate innovation into its own category.

On the one hand, leaving innovation out of the business agility equation misses the strategic importance of agility, as resilience and responsiveness are only tactical benefits. Innovativeness, however, means the ability to intentionally introduce change into the business environment in order to achieve strategic advantage.

There is more to this connection between responsiveness and resilience on the one hand and innovation on the other, however, depending upon your point of view. I came to this conclusion during a conversation with a consultant who focuses on providing innovation to her clients. The challenge she faced wasn’t providing innovative products and services for her clients. The challenge was how to get them past their fear of the change that such innovations represented.

Fear of change, of course, is the primary roadblock to business agility in any organization. Many organizations, unfortunately, have no effective means for dealing with such fear. Management consultants speak of developing a “culture of innovation” or some such, but fail to provide an effective means for fostering such a culture. Bloomberg Agile Architecture can help.

Considering innovativeness to be one facet of business agility provides a different route to resolving the fear of innovation conundrum, as innovativeness is only part of the agility story. Resilience is also essential for business agility. We define resilience as the ability to respond to adverse change in the business environment – essentially, being able to bounce back when bad things happen. To increase your organization’s resilience, the first step is analyzing the sorts of bad things that might happen and how likely they are – in other words, you must conduct a risk analysis.

In the case of the fear of innovation, you must analyze the risks inherent in making the change under consideration as well as the risks of not making the change. The second part of this analysis is the most important, as you cannot create a risk profile unless you consider all sides of a decision, including the risks inherent in not making it.

Risk profile analysis, of course, is a central part of traditional information assurance – the risk management that goes on all the time in those parts of organizations that are familiar with quantifying risks. Credit card companies, for example, know how to calculate the risk of fraud, and balance that risk with how much it costs to combat fraud. The analysis should lead to the local optimum: the right balance between the cost of fraud and the cost of fighting it.

Just so with innovation. Calculate the risk of introducing a change – maybe customers don’t like the new product, maybe it cannibalizes existing revenues, etc. And then calculate the risk of not introducing the change – the competition’s innovations take your market share, the opportunity cost of leaving money on the table, existing product lines reach their saturation point or lose favor among customers, etc. Run the numbers and make your best guess as to the optimum balance between action and inaction (or in practice, among all the alternatives under consideration).

Fair enough, but what does this approach have to do with Agile Architecture? Remember, such architecture should focus on organizational, process, technology, and information design choices that support the agility drivers of the organization. The discussion up to this point has focused on organizational and process change. But without the appropriate supporting technology and information, it would be impossible to calculate an accurate risk profile analysis. The “running the numbers” step above is easier said than done, after all, as the necessary data might very well be the result of the appropriate application of Big Data analytics. Supporting the business agility goals of an organization by connecting them to the technology and information required to achieve those goals is the purpose of Bloomberg Agile Architecture. Make sure you’re not missing any of the pieces.

Posted by Jason Bloomberg on June 26, 2014

I read with interest JP Morgenthal’s recent post on how SaaS represents the commoditization of application functionality for enterprises. He points out that based upon a recent GigaOm research report, enterprises are in large part shifting away from on premise, custom software solutions to one-size-fits-all SaaS alternatives because businesses are realizing that “they can achieve the same goals with the commodity item as they can with the unique one.” JP goes on to say that businesses are still willing to pay the higher costs of bespoke solutions if they deliver sufficient value – but SaaS alternatives are increasingly carving out a larger portion of the enterprise app pie.

The reason I found this post interesting (JP’s scintillating insight notwithstanding) was because I just wrote a blog post on how software customization limits agility. I conclude that with proper architecture, it’s possible to build software flexible enough to support the organization’s business agility goals, even when those goals require a high level of personalization and customization, without falling into the high-cost bespoke software trap.

These two perspectives appear to be at odds with one another. JP is basically saying that as SaaS gets better, enterprises are more likely to settle for commoditized capabilities because of the cost savings, while I’m saying that as architecture gets better, enterprises are more likely to take advantage of high levels of personalization and customization, because Agile Architecture will enable such flexibility while keeping costs down. So, which is it?

The answer: both. With the proper architecture, commoditized software (even SaaS) can still be highly flexible. There’s nothing about my argument that wouldn’t apply to SaaS; in fact, I would expect an increasing percentage of well-architected software to be available in the Cloud (either PaaS or SaaS depending on which software we’re talking about).

Today, the ability to customize public SaaS offerings is limited primarily to user interface personalization, turning capabilities on and off for different users, and a modest level of configurability of the application functionality itself. But the writing is on the wall. Enterprises will only settle for “one size fits all” commoditization of SaaS apps if the cost savings outweigh the limitations, and if there’s nothing better on the market. Once the SaaS vendors figure out how to offer full-fledged mass customization while maintaining a commoditized code base, enterprises won’t have to settle for any color as long as it’s black any more.

If you’re a SaaS vendor, the rules are changing as we speak. Building your entire business on offering commoditized software will eventually be a losing value proposition, as downward pricing pressure will catch up with you sooner or later. But if you don’t figure out how to scale mass customization without driving up costs, you’ll be eaten alive. The secret, of course, is to get your architecture right from the beginning.

Posted by Jason Bloomberg on June 25, 2014

Can you imagine this scenario? You’re monkeying with your app of choice, say from Apple or Microsoft or perhaps from any of the throngs of vendors pouring new apps in to the consumer market. The app in question is OK, but you’d really like it to do something else – something it doesn’t currently do, and furthermore, the feature you want is likely only of interest to you. So you call the vendor. “Hello Apple? Yeah, I’d really like to have this new doohickey in my iTunes app. Can you build a custom version of it just for me? You can? Hey, thanks.”

Not on your life! Getting a vendor on the phone at all is difficult enough. If you actually have the chutzpah to ask them to recode their app just for you, they’ll laugh you off of the Internet.

Yet while that scenario strains credulity in the consumer market, many enterprise software customers are used to asking for code customizations from their commercial off-the-shelf (COTS) software vendors. After all, such software in the enterprise space can cost millions of dollars in licenses, and many more millions over time in maintenance. And what is software maintenance, when you get right down to it? Sure, it’s regular updates that everybody gets, but that’s not why maintenance costs you the limbs of your firstborn. The COTS vendors realize you’ll be asking for code customizations, so in many cases, maintaining such customizations is where the maintenance dollars go.

Of course, this problem is as old as the COTS marketplace, and vendors have been gradually getting wise. The reason customization is such a bear to deal with is that every code customization branches the code – making regular updates difficult or impossible. As a result, over the years vendors have reworked their software to be increasingly configurable.

The goal of configurability is to provide customization and personalization for customers while maintaining a single, easy to upgrade codebase. As long as the updated codebase is backward compatible with older configurations, then everybody’s happy – in theory. But in reality, it’s virtually impossible to shift all possible customer customization requirements to the declarative configuration layer. True, today’s enterprise COTS packages typically have configurable user interfaces, and perhaps offers features an administrator can turn on and off for different users, but more sophisticated customization requirements still require changing code.

The good news is, it’s possible to solve this agility-killing problem via the part of the Bloomberg Agile Architecture Technique I call a Business Agility Platform, for want of a better name (the marketplace may do better, but I’ll stick with the moniker Business Agility Platform in the meantime). I introduced this platform in a previous blog post when I introduced the notion of the tool-building platform (see the figure below).

Instead of expecting vendors to offer configurable software their customers can use to create customized configurations, I introduced a third layer. The tool-building Business Agility Platform offers affordances to developers who use it to create configurable applications by building abstract models of those applications. As a result, a wider range of users (perhaps developers, perhaps not) can use those application-building tools to build their applications via configuration alone.

In this model, upgrading the Business Agility Platform is straightforward, as all upgrades will simply add affordances – but existing affordances will remain, making the platform fully backward compatible. Furthermore, when a customer requires a change to a tool that they cannot make via their application configuration capability, then developers can customize the application-creation tool by changing the abstract model, which is inherently a reconfiguration, as the abstract model consists solely of metadata the underlying tool-building platform can interpret. Problem solved.

This three-layer approach is relatively straightforward, and each element of the approach – even the abstract models – leverages existing, well-established software approaches. The obvious question, therefore, is why aren’t more vendors building their offerings this way?

The answer: it’s not the software part of this story that’s new and different. It’s the architecture. This vision cuts across existing architectural silos, including software architecture, systems architecture, business architecture, and enterprise architecture, to offer a specific approach for building software that supports enterprise business agility requirements. And changing architecture is hard, especially when the new approach cuts across different specializations. The good news: the world is ready for Bloomberg Agile Architecture.

Posted by Jason Bloomberg on June 20, 2014

It’s impossible to adequately understand business agility without the appropriate level of systems thinking. After all, individual people and pieces of technology don’t exhibit business agility, organizations do. And yet, we cannot treat an organization as a traditional system. In fact, once we take the conceptual leap that organizations as a whole can exhibit business agility, while the people and technology components that make up the organization do not, then we have just cast business agility as an emergent property of the enterprise. The logical conclusion of this point is that enterprises are complex adaptive systems, systems of systems where the people and technology systems within the organization are the individual subsystems that self-organize within the enterprise.

This insight is meaningless, however, if we’re not able to translate it into practical steps for achieving business agility. The first of these steps is to break down the notion of business agility. I include responsiveness, resilience, and innovativeness in my definition of business agility because the organization itself must exhibit these qualities. However, other qualities such as versatility, flexibility, and adaptability would apply more to individual people or technology systems within the organization. This distinction is important, because we need to differentiate between emergent properties and ordinary properties, as how we influence such properties varies dramatically.

Thus properties like flexibility can lead to emergence, but not necessarily, and not predictably. And yet, it's possible for a vendor or technology team to build flexible software. The Agile Architecture challenge, then, is to help the organization understand how changing the behavior of subsystems (people and technology) affect the behavior of the organization overall in order to achieve the business agility goals of the enterprise. How to accomplish this task is core to the Bloomberg Agile Architecture (BAA) Technique.

When you allow a complex adaptive system to run on its own for a while, it ends up in one of four basic states: stable, cyclical, chaotic, or a distinct pattern. In the case of an enterprise, stable and cyclical are out of the question. Instead, we have two possibilities: chaotic, or the distinct pattern we’re going to call agile. The challenge of BAA, therefore, is to move away from chaotic, which is the usual behavior of an enterprise, to agile.

All we have to work with in order to affect this change are the component systems – people and technology systems. To affect the behavior of these subsystems, we need to minimize adverse events while emphasizing positive behaviors that lead to the emergent properties we are looking for, as opposed to the usual chaos. In fact, that concept is the thrust of the entire first section of my book, The Agile Architecture Revolution. I'm expanding and deepening that thinking in the BAA Technique -- as well as providing practical advice for how to get it all to work in practice.

So far so good, but how much business agility do we need, anyway? And how much is all this architecture work going to cost? Do we need to hammer out all the details ahead of time in order to set a budget? The answer is, in part. It's important for the architects to understand the agility drivers of the organization, which will necessarily include budgetary considerations. But it's a fool’s errand to believe it's possible to pin down agility requirements sufficiently to assign a firm budget. After all, we're talking about agility here! The whole point is that we're expecting everything to change.

The better approach is to get a broad, high-level understanding of the business agility drivers, and then iterate. Create a tentative roadmap, maturity model, and enterprise architecture. Identify and complete a pilot project. Analyze the results of the pilot and feed back that analysis in order to adjust the business case, which will also lead to adjustments of the budget. Then iterate again, solving real problems in each iteration while the overall maturity of the approach improves.

Of course, there's a lot more to say on this subject. I'll continue to provide the details over time. This approach is also the subject of my course, The Bloomberg Agile Architecture Certification Course, as well as the advisory I do with management and architecture teams. Drop me a line for more information.

Posted by Jason Bloomberg on June 18, 2014

Over the last few weeks I’ve conducted briefings with several vendors in support of my upcoming Agile Architecture Vendor Landscape report. The purpose of the report is to help enterprise IT decision makers understand what technologies and service offerings are on the market today that can help support the Bloomberg Agile Architecture (BAA) vision. After all, while Intellyx as a company as well as BAA focus on business agility as the core driver for organizations, at its core, BAA is a technology-driven architectural technique. The business people can talk about agility, while the techies can talk about Agile, and BAA connects the dots. But even the best architecture technique is little more than words and diagrams on paper without effective technology to support the architecture – and that’s where the Agile Architecture Vendor Landscape comes in.

The vendors I’ve selected for this first round of briefings all talk about agility. After all, talking about agility is easy. The problem I’m running into, however, is that actually delivering technology that supports customers’ agility drivers is hard. And furthermore, it’s much harder for well-established vendors than for newer vendors who have come to market more recently. (Drop me a line if you’re a vendor who would like to be included in this report.)

As I discuss in depth in my business-focused Agility Workshops as well as the BAA Certification course, business agility breaks down into three separate business drivers: responsiveness, resilience, and innovativeness. Responsiveness means being able to respond quickly and efficiently to positive change, like shifting customer demand. Resilience refers to dealing with adverse change, mitigating security or compliance risks for example. But the most important of the three is innovativeness: being able to introduce change into the business environment in order to achieve a strategic benefit like increased market share or entry into new markets.

When vendors talk about agility, they are usually referring to responsiveness or resilience – which are important, but miss the big picture of agility. Supporting your customers’ ability to innovate requires exceptionally flexible technology, as the customer can’t tell you today what they’ll want from your technology tomorrow. If they were able to do so, they wouldn’t be innovative.

Of course, that doesn’t stop vendors from saying they can help customers innovate. What I’m finding as I conduct my research is that in large part, supporting innovation is little more than handwaving on the part of most vendors – what I like to call agility at the PowerPoint layer, especially if the vendor has older, less flexible technology under the covers.

This lesson applies equally well inside an enterprise IT shop. Today’s CIOs (like the CIO of the fictitious company Horizon in my last Cortex newsletter) are faced with lines of business who wish to innovate, so those managers are relying increasingly on shadow IT for technologies that support such innovation. Meanwhile, the systems of record and other legacy are stuck in the dark ages, unable to provide agility of any kind. The questions any IT executive in a similar situation must ask: are my purported “systems of innovation” really providing innovativeness, in spite of our legacy boat anchor? Or are the vendors providing products and services for such systems simply touting agility at the PowerPoint layer? Don’t be fooled. Agility is harder than it sounds, especially when older technology runs the business.

Posted by Jason Bloomberg on June 12, 2014

I had the pleasure of delivering my first conference presentation as the President of Intellyx yesterday at Cloud Expo in New York. My talk, Breaking Down Enterprise Silos in the Cloud, introduced Bloomberg Agile Architecture to a live audience (download the presentation from SlideShare). I’m pleased (and relieved!) to say the reaction was quite positive. The feedback centered on the breadth of the vision: yes, Cloud was a part of the story, but I touched upon organizational change, Agile methodologies, next-Generation SOA, DevOps, and more. After a day of Cloud-related sales pitches from vendors, my “the world isn’t all about the Cloud” angle was a welcome relief for my audience.

Furthermore, Intellyx’s focus on business agility, rather than on a particular technology trend or industry, is also receiving quite positive feedback. Too many of the presentations at technology conferences forget that the point to technology is to solve business problems. As a result, my agility-driven message was understood and appreciated.

But perhaps the most insightful comment came from a fellow who worked at one of the large logistics/package delivery companies. He came up to me after my talk and explained how they scan every package several times as it moves through their process (which I knew), and how an additional bar code label is automatically applied at a certain point that directs sorting equipment to put the package on the proper shelf in the proper truck (which I didn’t). His point was that their company was an information company, not a package delivery company. Without the ability to leverage information to automate their processes, they wouldn’t have a business at all.

The notion that information technology is the business is a point that underlies the entire Bloomberg Agile Architecture vision, and in fact, is a notion that I feature on the Intellyx Web site – but I didn’t explicitly include that notion in my presentation for Cloud Expo. I am pleased, therefore, that my audience was able to understand the more profound principles behind breaking down enterprise silos in the Cloud.