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.

?

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.