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

Posted by Jason Bloomberg on August 26, 2014

I attended Dataversity’s NoSQL Now! Conference last week, and among the many vendors I spoke with, one story caught my interest. This vendor (who alas must remain nameless) is a leader in the NoSQL database market, specializing in particular on supporting XML as a native file type.

In their upcoming release, however, they’re adding JavaScript support – native JSON as well as Server-Side JavaScript as a language for writing procedures. And while the addition of JavaScript/JSON may be newsworthy in itself, the interesting story here is why they decided to add such support to their database.

True, JavaScript/JSON support is a core feature of competing databases like MongoDB. And yes, customers are asking for this capability. But they don’t want JavaScript support because they think it will solve any business problems better than the XML support the database already offers.

The real reason they’re adding JavaScript support is because developers are demanding it – because they want JSON on their resumes, and because JSON is cool, whereas XML isn’t. So for the people actually responsible for buying database technology, they’re asking for JSON support as a recruitment and retention tool.

Will adding JavaScript/JSON support make their database more adept at solving real business problems? Perhaps. But if developers will bolt if your database isn’t cool, then coolness suddenly becomes your business driver, for better or worse. One can only wonder: how many other software features are simply the result of the developer coolness factor, independent of any other value to the businesses footing the bill?

Posted by Jason Bloomberg on August 21, 2014

In my latest Cortex newsletter I referred to “tone deaf” corporations who have flexible technology like corporate social media in place, but lack the organizational flexibility to use it properly. The result is a negative customer experience that defeats the entire purpose of interacting with customers.

Not all large corporations are tone deaf, however. So instead of finding an egregious example of tone deafness and lambasting it, I actually found an example of a corporation who uses social media in an exemplary way. Let’s see what Delta Airlines is doing right.

The screenshot above is from the Delta Facebook page. Delta regularly posts promotional and PR pieces to the page, and in this case, they are telling the story of a long-time employee. Giving a human face to the company is a good practice to be sure, but doesn’t leverage the social aspect of Facebook – how Delta handles the comments does.

As often happens, a disgruntled customer decided to post a grievance. Delta could have answered with a formulaic response (tone deaf) or chosen not to respond at all (even more tone deaf). But instead, a real person responded with an on-point apology. Furthermore, this real person signed the response with her name (I’ll assume Alex is female for the sake of simplicity) – so even though she is posting under the Delta corporate account, the customer, as well as everybody else viewing the interchange, knows a human being at Delta is responding.

If Alex’s response ended at a simple apology, however, such a response would still be tone deaf, because it wouldn’t have addressed the problem. But in this case, she also provided a link to the complaints page and actually recommended to the customer that she file a formal complaint. In other words, Delta uses social media to empower its customers – the one who complained, and of course, everyone else who happens to see the link.

It could be argued that Alex was simply handing off the customer to someone else, thus passing the buck. In this case, however, I believe the response was the best that could be expected, as the details of the customer’s complaint aren’t salient for a public forum like social media. Naturally, the complaints Web site might drop the ball, but as far as Delta’s handling of social media, they have shown a mastery of the medium.

So, who is Alex? Is she in customer service or public relations? The answer, of course, is both – which shows a customer-facing organizational strategy at Delta that many other companies struggle with. Where is your customer service? Likely in a call center, which you may have even outsourced. Where is your PR? Likely out of your marketing department, or yes, even outsourced to a PR firm.

How do these respective teams interact with customers? The call center rep follows a script, and if a problem deviates, the rep has to escalate to a manager. Any communications from the PR firm go through several approvals within the firm and at the client before they hit the wire. In other words, the power rests centrally with corporate management.

However, not only does a social media response team like Alex’s bring together customer service and PR, but whatever script she follows can only be a loose guideline, or responses would sound formulaic, and hence tone deaf. Instead, Delta has empowered Alex and her colleagues to take charge of the customer interaction, and in turn, Alex empowers customers to take control of their interactions with Delta.

The secret to corporate social media success? Empowerment. Trust the people on the front lines to interact with customers, and trust the customer as well. Loosen the ties to management. Social media are social, not hierarchical. After all, Digital Transformation is always about transforming people.

Posted by Jason Bloomberg on August 12, 2014

Two stories on the Internet of Things (IoT) caught my eye this week. First, IDC’s prediction that the IoT market will balloon from US$1.9 trillion in 2013 to $7.1 trillion in 2020. Second, the fact it took hackers 15 seconds to hack the Google Nest thermostat – the device Google wants to make the center of the IoT for the home.

These two stories aren’t atypical, either. Gartner has similarly overblown market growth predictions, although they do admit a measure of overhypedness in the IoT market (ya think?). And as far as whether Nest is an unusual instance, unfortunately, the IoT is rife with security problems.

What are we to make of these opposite, potentially contradictory trends? Here are some possibilities:

We simply don’t care that the IoT is insecure. We really don’t mind that everyone from Russian organized criminals to the script kiddie down the block can hack the IoT. We want it anyway. The benefits outweigh any drawbacks.

Vendors will sufficiently address the IoT’s security issues, so by 2020, we’ll all be able to live in a reasonably hacker-free (and government spying-free) world of connected things. After all, vendors have done such a splendid job making sure our everyday computers are hack and spy-free so far, right?

Perhaps one or both of the above possibilities will take place, but I’m skeptical. Why, then, all the big numbers? Perhaps it’s the analysts themselves? Here are two more possibilities:

Vendors pay analysts (directly or indirectly) to make overblown market size predictions, because such predictions convince customers, investors, and shareholders open their wallets. Never mind the hacker behind the curtain, we’re the great and terrible Wizard of IoT!

Analysts simply ignore factors like the public perception of security when making their predictions. Analysts make their market predictions by asking vendors what their revenues were over the last few years, putting the numbers into a spreadsheet, and dragging the cells to the right. Voila! Market predictions. Only there’s no room in the spreadsheet for adverse influences like security perception issues.

Maybe the analysts are the problem. Or just as likely, I got out on the wrong side of bed this morning. Be that as it may, here’s a contrarian prediction for you:

Both consumers and executives will get fed up with the inability of vendors to secure their gear, and the IoT will wither on the vine.

The wheel is spinning, folks. Which will it be? Time to place your bets!

the IoT will wither on the vine

Posted by Jason Bloomberg on August 8, 2014

One of the most fascinating aspects of the Agile Architecture drum I’ve been beating for the last few years is how multifaceted the topic is. Sometimes the focus is on Enterprise Architecture. Other times I’m talking about APIs and Services. And then there is the data angle, as well as the difficult challenge of semantic interoperability. And finally, there’s the Digital Transformation angle, driven by marketing departments who want to tie mobile and social to the Web but struggle with the deeper technology issues.

As it happens, I’ll be presenting on each of these topics over the next few weeks. First up, a Webinar on Agile Architecture Challenges & Best Practices I’m running jointly with EITA Global on Tuesday August 19 at 10:00 PDT/1:00 EDT. I’ll provide a good amount of depth on Agile Architecture – both architecture for Agile development projects as well as architecture for achieving greater business agility. This Webinar lasts a full ninety minutes, and covers the central topics in Bloomberg Agile Architecture™. If you’re interested in my Bloomberg Agile Architecture Certification course, but don’t have the time or budget for a three-day course (or you simply don’t want to wait for the November launch), then this Webinar is for you.

Next up: my talk at the Dataversity Semantic Technology & Business Conference in San Jose CA, which is collocated with their NoSQL Now! Conference August 19 – 21. My talk is on Dynamic Coupling: The Pot of Gold under the Semantic Rainbow, and I’ll be speaking at 3:00 on Thursday August 21st. I’ll be doing a deep dive into the challenges of semantic integration at the API level, and how Agile Architectural approaches can resolve such challenges. If you’re in the Bay Area the week of August 18th and you’d like to get together, please drop me a line.

If you’re interested in lighter, more business-focused fare, come see me at The Innovation Enterprise’s Digital Strategy Innovation Summit in San Francisco CA September 25 – 26. I’ll be speaking the morning of Thursday September 25th on the topic Why Enterprise Digital Strategies Must Drive IT Modernization. Yes, I know – even for this marketing-centric Digital crowd, I’m still talking about IT, but you’ll get to see me talk about it from the business perspective: no deep dives into dynamic APIs or Agile development practices, promise! I’ll also be moderating a panel on Factoring Disruptive Tech into Business with top executives from Disney, Sabre, Sephora, and more.

I’m particularly excited about the Digital Strategy Innovation Summit because it’s a new crowd for me. I’ve always tried to place technology into the business context, but so far most of my audience has been technical. Hope you can make it to at least one of these events, if only to see my Digital Transformation debut!

Posted by Jason Bloomberg on August 1, 2014

What’s wrong with this scenario? Bob, your VP of Engineering brings a ScrumMaster, a Java developer, a UX (user experience) specialist, and a Linux admin into his office. “We need to build this widget app,” he says, describing what a product manager told him she wanted. “So go ahead and self-organize.”

Bob’s intentions are good, right? After all, Agile teams are supposed to be self-organizing. Instead of giving the team specific directions, he laid out the general goal and then asked the team to organize themselves in order to achieve the goal. What could be more Agile than that?

Do you see the problem yet? Let’s shed a bit more light by snooping on the next meeting.

The four techies move to a conference room. The ScrumMaster says, “I’m here to make sure you have what you need, and to mentor you as needed. But you three have to self-organize.”

The other three look at each other. “Uh, I guess I’ll be the Java developer,” the Java developer says.

“I’ll be responsible for the user interface,” the UX person says.

“I guess I’ll be responsible for ops,” the admin volunteers.

Excellent! The team is now self-organized!

What’s wrong with this picture, of course, is that given the size of the team, the constraints of the self-organization were so narrow that there was really no organization to be done, self or not. And while this situation is an overly simplistic example, virtually all self-organizing teams, especially in the enterprise context, have so many explicit and implicit constraints placed upon them that their ability to self-organize is quite limited. As a result, the benefits the overall application creation effort can ever expect to get from such self-organization is paltry at best.

In fact, the behavior of self-organizing teams as well as their efficacy depend upon their goals and constraints. If a team has the wrong goals (or none at all) then self-organization won’t yield the desired benefits. Compare, for example, the hacker group Anonymous on the one hand with self-organizing groups like the Underground Railroad or the French Resistance in World War II on the other. Anonymous is self-organizing to be sure, but has no goals imposed externally. Instead, each individual or self-organized group within Anonymous decides on its own goals. The end result is both chaotic and unpredictable, and clearly makes a poor example for self-organization for teams within the enterprise.

In contrast, the Underground Railroad and the French Resistance had clear goals. What drove each effort to self-organize in the manner they did were their respective explicit constraints: get caught and you get thrown in jail or executed. Such drastically negative constraints led in both cases to the formation of semi-autonomous cells with limited inter-cell communication, so that the compromise of one cell wouldn’t lead to the compromise of others.

In the case of self-organizing application creation teams, goals should be appropriately high-level. “Code us a 10,000-line Java app” is clearly too low-level, while “improve our corporate bottom line” is probably too high-level. That being said, expressing the business goals (in terms of customer expectations as well as the bottom line) will lead to more effective self-organization than technical goals, since deciding on the specific technical goals should be a result of the self-organization (generally speaking).

The constraints on self-organizing teams are at least as important as the goals. While execution by firing squad is unlikely, there are always explicit constraints, for example, security, availability, and compliance requirements. Implicit constraints, however, are where most of the problems arise.

In the example at the beginning of this article, there was an implicit constraint that the team had precisely four members as listed. In real-world situations teams tend to be larger than this, of course, but if management assigns people to a team and then expects them to self-organize, there’s only so much organizing they can do given the implicit management-imposed constraint of team membership.

Motivation also introduces a messy set of implicit constraints. In enterprises, potential team members are generally on salary, and thus their pay doesn’t motivate them one way or another to work hard on a particular project. Instead, enterprises have HR processes for determining how well each individual is doing, and for making decisions on raises, reassignments, or firing – mostly independent from performance on specific projects. Such HR processes are implicit constraints that impact individuals’ motivation on self-organizing teams – what Adrian Cockcroft calls scar tissue.

A Hypothetical Model for True Self-Organization on Enterprise Application Creation Teams

What would an environment look like if the implicit constraints that result from traditionally run organizations, including management hierarchies and HR policies and procedures, were magically swept away? I’m still placing this discussion in the enterprise context, so business-driven project goals (goals that focus on customers/users and revenues/costs) as well as external, explicit constraints like security and governmental regulations remain. Within those parameters, here’s how it might work.

The organization has a large pool of professionals with a diversity of skills and seniority levels. When a business executive identifies a business need for an application, they enter it into an internal digital marketplace, specifying the business goals and the explicit constraints, including how much the business can expect to pay for the successful completion of the project given the benefits to the organization that the project will deliver, and the role the executive as project stakeholder (and other stakeholders) are willing and able to play on the project team. The financial constraint may appear as a fixed price budget or a contingent budget (with a specified list of contingencies).

Members of the professional pool can review all such projects and decide if they might want to participate. If so, they put themselves on the list for the project. Members can also review who has already added themselves to the list and have any discussions they like among that group of people, or other individuals in the pool they might want to reach out to. Based upon those discussions, any group of people can decide they want to take on the project based upon the financial constraints specified, or alternately, propose alternate financial arrangements to the stakeholders. Once the stakeholders and the team come to an agreement, the team gives their commitment to completing the project within the constraints specified. (Of course, if there are no takers, the stakeholder can increase the budget, or perhaps some kind of automated arbitrage like a reverse auction sets the prices.)

The team then organizes themselves however they see fit, and executes on the project in whatever manner they deem appropriate. They work with stakeholders as needed, and the team (including the stakeholders) always has the ability to adjust or renegotiate the terms of the agreement if the team deems it necessary. The team also decides how to divide up the money allotted to the project – how much to pay for tools, how much to pay for the operational environment, and how much to pay themselves.

Do your application creation teams self-organize to this extent? Probably not, as this example is clearly at an extreme. In the real world, the level of self-organization for a given team is a continuous spectrum, ranging from none (all organization is imposed by management) to the extreme example above. Most organizations fall in the middle, as they must work within hierarchical organizations and they don’t have the luxury (or the burden) of basing their own pay on market dynamics. But don’t fool yourself: simply telling a team to self-organize does not mean they have the ability to do so, given the goals and constraints that form the reality of the application creation process at most organizations.

Posted by Jason Bloomberg on July 24, 2014

Parenting is perhaps the most difficult job any of us is likely to have in our lifetimes, and we earnestly do our best as a rule. And yet, some parenting styles are clearly better than others.

The same is true of architecture. Even the best architects will admit that architecture is difficult, and even though we all try to do our best, in many cases architects are at the least ineffective, and at the worst, do more harm than good.

As it happens, there are some interesting parallels between parenting and architecting. Let’s start with the two most common bad parenting styles: too strict, and not strict enough.

The too strict parent lays down the rules. There are plenty of rules to go around, and breaking them leads to adverse consequences. Such parenting leads to resentment and rebellion from the children.

Unfortunately, most architecture falls into the overly strict category. Architecture review boards that give thumbs up or thumbs down on everybody’s work. Copious design documents that everybody is supposed to follow. Policies and procedures out the wazoo. A rigid sense of how everything is supposed to work.

The result? No flexibility. Excess costs. Increased risk of spectacular failure. And of course, resentment and rebellion from the masses.

However, the opposite type of parenting style is also quite poor: the “anything goes” parent with no rules. Sure, if you’re a teenager it sounds good to have such a “cool” parent – but with no guidelines, parents aren’t teaching their children the basics of living in society. The common result: antisocial or dangerous behaviors like drug use, promiscuity, etc.

The enterprise parallel to the anything goes parent isn’t anything goes architects – it’s no architects at all (even though some people may have the architect title). Without any guidance, the architecture grows organically into a rats’ nest of complexity. No rules leads to a big mess, as well as dangerous behaviors like insufficient attention to security, disaster recovery, etc.

The best parent, of course, is the happy medium. A parent who establishes clear but reasonable guidelines that don’t prevent the kids from living their lives as they like, but keep them out of serious trouble and help them establish behaviors that will make them successful adults.

Just so with the best architects. Focus on what’s really important to architect, like your security, disaster recovery, and regulatory compliance. Provide clear but reasonable guidelines for interoperability among various teams, projects, and software. Act as a mentor and evangelist for architecture, without limiting the flexibility that people need to do their jobs well. And by all means, don’t spend too much time on artifacts, documentation, rules, policies, procedures, and other “stuff.” Yes, you sometimes need these things – but good architects know that the very minimum “stuff” that will get the job done is all the stuff you need.

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.