Thinking about the corollary between the JVM and enterprise infrastructure, one has to wonder if enterprise architects are putting as much thought into their infrastructure planning as Gosling and company put into designing the JVM. My suspicion is that they aren’t. Instead, what we more often see is the recapitulation of received knowledge rather than a reasoned reckoning of what the environment currently needs and how it can best accommodate changes in the enterprise. With this in mind, here are a few lessons I think most of us could learn from the development of the JVM².

• Look for Patterns in Smaller Systems – Most people know that Gosling & co started building Oak as a language for embedded systems (it was for interactive TV actually) and was built, in part, from the team’s observation of what made network-based programming hard. Lots of small libraries that with intricate detail that had to be understood thoroughly, variations in underlying computer hardware and it’s impact on the data layer and even the impacts of the network layers itself on the data being delivered. Rather than look at the problem as one of language design (and let’s remember – the point was to build a language), they looked at it from the perspective of someone building one system at a time – what are their needs? What makes their lives difficult? What mistakes do they make over and over again? What increases their chance of delivering bad code? In short, they realized that while the language itself was important, it was equally important to deliver an environment that allowed the language to address the needs of the individual program.Similarly, our infrastructure solutions need to take a similar approach – leveling the playing field for applications and allowing systems and platforms to focus on delivering functionality, not navigating the intricacies of downstream dependencies. This sounds pretty obvious, but a brief look in the ESB-space proves otherwise. How many ESB solutions force systems to adhere to a standard model and then force every single system to implement adapters to conform to this model? This type of ESB doesn’t facilitate integration; it just ensures that everyone who touches the ESB has to become an expert in that particular ESB! Infrastructure should make itself as transparent as possible to the systems taking advantage of them, not force participating systems into some architect’s favorite paradigm or data design.
• Be Open – The Java Community Process is a byzantine and sometimes cliquish thing. Generally speaking, there tends to be a set of “usual suspects” driving many of the more significant JSRs. These usual suspects run the gamut from open-minded to entrenched to a specific way of doing things. The voting lifecycle process within the JCP often makes a corporate governance meeting look like an exercise in agility. However, even with these criticisms, one is struck by how open the JCP really is. Think about it – anyone can join (individuals join free), anyone can view the draft specifications as they are developed and even propose a new specification. And all of this has been in place and working for over 10 years – not bad.
• I often hear protests from those running technology strategy, governance and infrastructure programs that openness is all well and good, but it has no place in a mature enterprise. This is pure drivel. The fact of the matter is that your enterprise almost certainly has rules for determining what is classified/confidential and what is not. And if you were to look carefully, I suspect you would find that 90% of the work done within these groups does not meet these criteria. Further, hiding this type of information from teammates is ultimately counterproductive – how can you expect teams to execute/use your infrastructure if they don’t have any sense of buy-in – a sense of ownership? Worse, how can you be sure that you’ve adequately addressed the issues and details of your community without their involvement? It’s not unlike building a system without asking the users for requirements – sure, it’s possible, but it’s not smart.
• Do What You Need and Nothing More – The JVM is amazingly complete. Upon it, entire languages are built – often languages that are significantly different from one another. Why put so much effort into the JVM when, almost certainly, it could be less buggy and offer better performance if it were more customized to the language itself? Because the objective was to create a platform, not a programming language. To be clear, that platform needed a programming language to be useful, so they built that too. But look at all the things they didn’t build – no closures, no generics and a very primitive UI framework. Things were added as time went on (we’ll talk about that in a second), but overall, the JVM is a prime example of restraint – building that which is necessary to accomplish the task at hand elegantly and creating the tools for others to build that which is outside of the platform’s core mission.
  At the most basic level, architects love to deal with complexity and bring order to it. And let’s be honest – most architects love what they do. The problem with this love of organizing complexity is that it ignores the central question we should be asking when faced with complexity: is it even necessary? Too often, we architect infrastructure for every possible inevitability. This type of mentality creates a misappropriation of our design time and effort – we need to be ensuring that our designs are robust, stable and ready to embrace change. Planning for every inevitability generally leads to heartache as we discover in the coming years that we missed one or two (or in reality, five or six…). Instead of planning for every inevitability, we should be building systems that support enhancement from arbitrary sources – both through direct code changes and through decorators provided by other actors in the environment. This latter option is one that many architects struggle with, considering it “bad design” to allow for externalized extension of system. However, nothing could be further from the truth – isn’t this what we do whenever we allow scripting in an application? When a framework is extended? Why shouldn’t the same principle apply to entire systems? With the correct controls, interfaces and governance, this practice allows your infrastructure team to focus on delivering solid infrastructure while simultaneously tapping into the creativity and talent of other teams.
• Start Small – No, this isn’t a play on the fact that the JVM was originally targeted at embedded systems. Instead, we’re going to focus on the actual size of the JVM and the code that runs upon it. Have you ever looked at the size of the JVM and class files? They’re shockingly small – especially for those of us who come from a Smalltalk background and are used to every single application starting at a massive size. You don’t get to this sort of efficiency by accident. It makes sense if you think about it: if you’re going to be tossing executable code across a network, you want it to be as compact and efficient as possible (such as with applets). Similarly, a network-based interpreter should be similarly compact, providing a complete execution environment in the smallest size possible.Efficiency isn’t something we hear much about in enterprise architecture nowadays. We talk about scalability and performance and resiliency, but not efficiency. Fundamentally, this results a failure in architecture to look at root causes. Efficient systems are those that display clear about what the purpose of the components is while ensuring that components that need to talk to each other can and those that don’t, can’t. These sorts of systems perform because they’ve been designed to perform, not because they designed one way and then optimized (often in conflict with the original design). These systems scale because they are minimalist – they allow trivial scaling of lightly integrated components while allowing attention to be paid to the more difficult (and often more important) highly integrated components.
• Don’t Fear Change – By my count, at least 6 of the 7 revisions of Java have resulted in significant changes to the JVM itself. Let that sink in for a bit – on at least six occasions, the infrastructure for the entire Java language was changed in such a way that “legacy” binaries (bytecode) was rendered unable to execute. When you think about it, that’s pretty ballsy. Why do it? Because (right or wrong) Sun felt it was necessary to make significant changes to the Java language and the best way to execute this change was to “break” compatibility.Most enterprise architects are horrified at this notion.
  Backwards compatibility is a cherished ideal and a sign of the loose coupling that we want to see in system architecture. This is a good and healthy look at architecture – we should be looking to create designs that prevent other systems to change whenever another makes an update. At the same time, fear of making incompatible changes is a debilitating problem that can leave you with a well-designed, but ineffectual system – and that’s bad architecture. Architects have to be willing to cut the cord; to say: this change will be significant, but it is necessary to meet the business need (current and future). Architects have to be willing to let go of the past and move in the interest of the business, even when it’s messy at a technical level.
• Ask for Feedback – The JSR process can be pretty rough and tumble.  People come from many different perspectives with their own agendas and biases and sometimes that comes out pretty harshly.  So why does Sun/Oracle even bother?  Wouldn’t it be easier to just invite the people in the industry who already work for/agree with them?  It would be easier, but it wouldn’t be better.  Nearly every major change to the Java programming language over the last 13 years has been the result of a collaboration between Sun/Oracle and the Java-using community.  This Java Community Process (JCP) facilitates interaction, mines the community for ideas and prevents myopia from setting in.  At a very fundamental level, collaboration breeds better design.
  I think it’s fair to say that  most architects “get” this idea at a pretty basic level.  Let’s face it, we’re a pretty talkative bunch.  Where I generally see problems arise is when talking doesn’t turn into collaboration. Too many times, we become entrenched in our thinking – focused on our first idea and unwilling to see it challenged or questioned.  Design requires a give and take – an advancing of ideas until another idea spears it, allowing a different, better idea to take it’s place. This is a somewhat adversarial process: the dominant idea/design is a protagonist, bravely representing the future.  Other architects have a responsibility to look for holes and weaknesses, for alternatives and for unexpected consequences to/of the original design/idea.  This is essential for the best idea to evolve.  Besides, if your original idea turns out to be the best, you get brownie points with your fellows for being just that smart.

Hrmmm…this seems to have gone a bit longer than I originally expected (I’m pretty sure I’ve written shorter magazine articles).  Regardless, I think the group at Sun has done a lot of “right” things with their development and nurturing of the JVM – most of which I think can teach us a lot about good architecture.

1: Yes, Microsoft’s CLR has a number of languages implemented as well, but the majority of these originated with the primary vendor, Mircrosoft.

2: For the purposes of this discussion, any reference to “infrastructure” refers to software infrastructure unless otherwise stated.

I’ve been reading a number of “strategy” books lately and there’s an idea that sticks out with regards to all this – if you’re forced to spend money on maintenance, then your thinking on initiatives becomes more tactical – the business begins to assume that innovation can’t take place and stops planning for it. The result is a self-fufilling prophecy that eventually leads to an eventual downturn in the business that worsens the situation further.

And to be honest, this sort of exercise serves a purpose.  First, it helps to keep technical skills sharp.  Many architects allow their technical/design skills to atrophy – the detail-oriented and often highly technical nature of this type of design is ideal for honing or refreshing an architect’s skills.  In addition, this sort of activity can often reveal new details or aspects of an architecture that escape notice during more traditional analysis.

All of that said, over optimization can be a very real problem if allowed to proceed beyond a reasonable point.  Other than draining resources from more productive endeavors, over optimization can actually result in damage to the integrity of the architecture.  Over specialization of any component of an architecture can result in processing issues within the larger architecture.  A useful rule of thumb is to ask a very basic question: what are we getting from this optimization?  Is the benefit commensurate with the cost/effort of the optimization?  Admittedly, these are subjective questions, but that’s where the experience of the architect comes into play.  The important thing is that, regardless of the personal benefits of this type of activity, the appropriate trade-offs of this activity are being appropriately examined and balanced.

I spoke with several of the architect’s peers (at the time, this individual was unfamiliar to me) and found that this was a nearly universal opinion: the individual in question is clever, has good ideas, but lacks the ability to effectively (and succinctly) convey these ideas.

So how does an architect develop the ability to communicate admittedly complex ideas in a way that is simple, succinct and compelling?  The most obvious answer is practice and feedback – lots and lots of feedback, much of it critical.  Beyond this, there are a few things that I’ve personally found useful:

• Err on the side of explanation – If there’s a chance that anyone might be unfamiliar with some term or concept, take a break and explain it.  Many people avoid this as they feel it detracts from the overall narrative, and in some cases, this is true.  However, taking a break to explain a difficult concept can be accomplished through an adjacent call out box or even a footnote.
• A picture is worth a thousand words – Most, if not all, architects are familiar with the value of diagramming a complex situation.  What many find difficult is abandoning technical schematics in favor of pictures that are vastly simpler, focusing on a few key concepts rather than strict technical completeness.
• Steal from the best – One of the best way to jumpstart your own ability to communicate is to study those who have already reached a level of mastery.  The number of books and blogs on the topic of information design are legion, but you don’t have to take the traditional route of study.  There are numerous magazines and newspapers that offer the opportunity to learn by example (USA Today, the New York Times and Wired magazine all regulatory feature great approaches to information design).

Regardless of how you approach the act of communicating with partners and peers, it is absolutely critical that you approach this part of the job as being equally important to the actual creation of a solution.  After all, if no one understands what you’re proposing, it doesn’t matter how brilliant it is.

• Original ideas that need more development
• Ideas that have already been done
• Ideas that don’t make sense in the current economic system (and don’t create an alternative)
• Ideas that require the startup to be a bank

This isn’t intended to be discouraging – there are a ton of great opportunities waiting for someone to jump on them.  Services like Mint, Wesabe and Prosper are great examples of services that do something new or differently enough to make a real impact.  There are a few simple questions that you can use to save yourself some time and effort when developing an idea:

• Does my idea dance around regulatory issues? You don’t want to mess with regulators.  Trust me on this.  If your idea has a chance of running afoul of one regulation or another, there’s a strong chance that there are several others that you’re not aware of.  If you’ve found one, you need to work with your legal team and start looking for the others.
• Does my idea do something that the banks CAN’T do? The simple fact of the matter is, if your idea is something that a bank could do, they will.  And they’ll do it better than you in all likelihood – they’re the incumbent here and they’ve got all the data.  Look for opportunities where you can aggregate across multiple banks or combine services in a way that regulated corporations can’t.
• Does my idea reinvent a business? Banks (like any established corporation) are notoriously bad at adjusting to large changes in the way business works.  A great example is the time it took most of the major banks to begin offering web-based banking services.  If you can get out there quickly and establish your brand, you’ll likely be sitting pretty for acquisition down the road.
• Will my idea create a bridge between individual consumers/companies beyond the banking relationship? One of the most poorly understood facets of banking is the relationship between consumers, producers and banks.  If your idea can successfully link these three entities in a unique or novel way, its chances of being viable go up significantly.
• Is my idea attacking an emerging or declining area of the business? I hear a lot of people nowadays pitching the next big idea in checking – when checking is a business on the decline with a foreseeable end of life.  Avoid these – go after areas that are emerging and just beginning to build momentum (in the current market, that would be card and mortgage).  Areas in between may be ripe for new ideas, but you’ll probably have a tougher time fighting against more established players (better defined markets tend to favor incumbents).
• Do you work for a bank? This is a tough one – if you already work for a bank, there’s a strong chance your idea might already be in jeopardy.  Most banks have fairly strict policies around the ownership of intellectual property rights even when they don’t have outright non-compete clauses.  Check with your lawyer before you accidentally land yourself in an expensive lawsuit.

If you can answer these questions to your own satisfaction, you may be on to something.  Otherwise, take what you’ve learned and reinvest the intellectual capital into a new venture.