Business and Technology Alignment

Large-growth technology start-ups still predominantly originate in Silicon Valley and Boston, but there's no reason why it can't happen here in the DC / Baltimore Alley. The raw materials and opportunities are here to both innovate and impact business and government on a grand scale, but the culture of business and technology are not aligned in that mission the way they need to be. To succeed as a tech-driven or tech-reliant innovator, leadership must drive execution top down to align business opportunity with technical excellence and foster this constant balance of values as part of their culture. Every employee has got to be in a position to contribute on both ends of the equation and have the support and incentives to do so.

Having worked with and in multiple technology startups in all these areas, I've seen first-hand that the differences are stark. Successful tech startups in "The Alley" tend toward sales and business heaviness. While this drives revenue and validates opportunity early (which is excellent) serious issues arise at scale when sound, experienced technical leadership and decision making isn't proactively integrated into the culture and DNA. Great ideas and opportunities without technical execution are doomed to failure as reality strays more and more from the promises of sales and marketing. Worse yet, the repeating pattern of this misstep creates a false perception that the talent for technical execution and innovation is not to be found in the area at all. In this scenario, perception becomes self-fulfilling prophecy driven by poor selection and fostering of talent at the highest levels.

On the other side of the coin "The Alley" is brimming with brilliant and experienced technologists doing amazing things with what they know about both their trade and industry. Unfortunately, very few of them are looking at the alignment of that work with the business opportunity that could elevate them to innovation greatness. More than that, the syndrome above promises them little hope of reward or recognition for bridging this gap or for partnering with those with the business acumen they so desperately need. The "culture of misalignment" strikes again here, discouraging or preventing technologist from working at this balance in themselves and their organizations. The syndrome's final outcome is an "us and them" mentality that promotes technical mediocrity, which tends to be predictable and tactical - focused on low risk, low value "wins" and distance from largely orphaned, higher-risk, more innovative efforts that may or may not be overly ambitious.

Enterprise Architecture professionals and practices have been pushing this alignment top down in large organizations for decades and "The Alley" is a veritable gold mine of those professionals. That being said, especially in a young tech company, the continued ability to execute and get your hands dirty at the leadership level is still critical. In fact, Silicon Valley companies like Google and Amazon still look for that kind of background from their leaders and regularly recruit and relocate from here. Finding the right technical leaders, empowering them, and making sure that the whole organization is built to reward strategic innovation, measured risk taking, and technical excellence that maps to the bottom line and competitive advantage is the most critical commitment a company can make.

The commitment to business and technical alignment is the key missing piece in the alley's start-up culture. Where there has been success here, you'll see exceptions to the rule and people willing to truly push the envelope. Building a culture that evangelizes, fosters, and rewards this re-alignment could fundamentally transform the innovation landscape in the area and set the tone to make the alley a hub of new kinds of companies built around the unique value propositions available.

The Ruby PHP Java Battle

Even though there are impressive solutions being built today on Ruby on Rails and PHP and even though those languages have some clear advantages, when you have to build a serious computing solution you need a language that can handle the heavy lifting. Today's Internet projects all have different value propositions and many are all about simple data and content (articles, blog entries, pictures, and videos) getting from source to repository and then out to the audience. Even Facebook fits mostly into this category and it has proven you can build a very powerful and successful communication vehicle for millions of people using PHP. In contrast, Google builds almost all of its solutions in compiled languages like Java (GWT is an entire RIA framework that powers Google Calendar, and Google Analytics to name a few) and they are solving equally valuable but somewhat more complex problems.

The massive set of well-structured APIs and libraries for manipulating data and networks and managing machine-to-machine communication using Java give it a huge advantage over scripting solutions. Today's Java community allows you to make five servers talk to one another securely and smash data in memory to achieve distributed data-crunching solutions or cooperative web services in ways that Ruby and PHP cannot hope to compete with. Native binary communication between objects and other key operational advantages also put Java in a different weight class than these other solutions. Still, not every idea needs these advantages at the expense of time to market (or at least, not at first).

Most businesses are looking for instant gratification to quickly prove the viability of a business idea. A savvy entrepreneur will often look for an off-the-shelf product they can tailor to model their idea regardless of the technology. The drive to build tools that let an average person manipulate the Internet is a noble one and one that scripting languages have a leg up on to date. In fact, with the ongoing expansion of cloud-based services like Google Checkout, PayPal, Google Maps, and the like, there are more and more things a basic script-based web site can do without really needing the horse-power to actually implement anything major from scratch. Successful businesses are cobbled together quickly (this is often called a mash-up) everyday using this strategy on top of Ruby or PHP, sometimes using something like Drupal or Wordpress as a baseline.

Once an idea or business grows to the point where real integration or large-scale problem solving is required, the immediate gratification advantages scripting allows in earlier stages begins to disappear entirely. The more successful the idea the worse this problem becomes and soon the difference between deploying changes to a Ruby, PHP, and Java solution vanish.

The Java community has been solving scaling and distributed computing problems for a lot of years and has learned a ton from the Ruby / PHP communities about time to market and flexibility. In fact, the entire Java community has been re-tooling to close the surface-level flexibility gap and is now very close to complete success. Companies like Firejack Technologies are pushing that envelope every day in fact, hoping to save early stage companies the re-tooling effort that often becomes critical for survival in competitive industries.

The goal is to achieve completely re-configurable services and application that don't require code changes to alter basic functionality. Business rules, security settings, page layouts, look and feel control, and user-experience really don't belong in code at all, but the Java solutions to do these things are still not accessible to average people. This is only a matter of time though, and soon the gap will close completely.

For many businesses, their growth problems begin with operational issues that require workflow, security, auditing, complex accounting, and advanced business analytics. Cloud based and off-the-shelf offerings can solve some of the basic problems, but the integration, scaling, and security concerns soon become far too complex for the small advantages that the scripting solution may have to matter. What is more, very few of the actual service providers themselves are using scripting languages to build their solutions, and for good reason.

In the end, companies or developers out to solve tomorrows problems and provide services to other people the way Google, PayPal, and Facebook do would be better off using Java from the beginning. Keep in mind Facebook was just a web site and came into billions of dollars before they started re-defining the Internet and they could afford to sink as much time and energy as they liked into making their technology compete. In the near future, there will be tools that rival all of the advantages of scripting languages and still give Java programmers the power tools to make incredible innovations happen. For businesses that are all about information for consumers, scripting may still be your best friend, but for the rest, making the right technology choice up front can be the difference between raging success and squandered potential greatness.

Domain Driven: The Consumer is King

One of the key reasons great software is successful is that it does a very good job of using metaphors and representations of information that everyone understands. Consumers of software systems must dictate the language used to deal with work or intuition works against them at every turn. This Domain Dictionary of terms, concepts, and metaphors are already in use wherever we build software and whether it's inherited from generally accepted concepts like finance or accounting, an established industry like publishing or banking, or are part of what differentiates the way a specific organization operates from another, years of evolution have ingrained the ideas (if not the entire lexicon) of the Domain Language in the minds of your customers.

The Domain Driven community refers to the result of capturing the domain language as a Ubiquitous Language stating that the terms of the language should proliferate all communication and code. This concept is among the most powerful concepts in Domain Driven Design and incredibly valuable in ensuring all members of a project team and the stakeholders communicate and share information properly. In the end, every API, class name, package name, URL pattern, e-mail must reference the domain language (or ubiquitous language) and a good architect will ensure that these definitions are up to date and spread across the team in some easily accessible and referable form (wikis make a great repository for the glossary).

What is key about this approach is that it alters the typical entity strategy (ground-up) construction of a system when done properly and focuses on the consumer of the system and its services first (top-down). This means leading with the language the consumers already use (and visualizations that make sense helps too) all the to the field level and making a commitment to every known view of information as they understand it. It also means abandoning the urge to force new metaphors or force-feed vocabulary (at least as much as possible) on the consumers (your customer) and an expectation that the architect and development team will handle translation of the conceptual model or domain model to the underlying Entity Model (that deals more directly with data as it's stored in a database).

If necessary, this abstraction can carry down to the data model in the form of views or materialized views particularly if your consumers feel strongly about reporting from the data model directly. Ideally, the chosen system architecture should supports a remote Services API layer, a business domain services layer, and a separate data access layer where domain data objects (DTOs or VOs) can be translated into more granular or less business friendly (although you should keep this minimal if possible) Entity Model representations. Still, the code at the domain data layer should be almost understandable to anyone in the domain because it should be completely reliant on actions and domain information definitions directly from the Domain Language Lexicon (DLL) or Dictionary (DLD). Actions, Entities (or Objects), Processes, and Events will make up the backbone of the language and those names should show up across the code base to ensure easy mapping between requirements, code, and sub-systems.

The more the underlying code base and user interface reinforce the DLD/DLL, the better chance of the development team delivering a system that is intuitive and clear to their consumers. The same goes for basic web services APIs and other integration points. The name of the game is consistent semantics across from top to bottom and clean, clear flow from one operation to the next. The great news is, great architecture strategies like MVC, OOD, N-Tier, Event-Driven, and Process Driven are all compatible with Domain Driven Analysis where the consumer is king. Done right, everyone wins and innovation will be well received because it will speak to everyone when it's delivered.