Entrepreneurs and Innovation

“Today, it is truer than ever that basic research is the pacemaker of technological progress”. This sentence was written in 1945 by Vannevar Bush in A Report to the President entitled Science the Endless Frontier. Bush lays out an argument for why and how the US Government can foster research activities by public and private institutions to maintain and enhance its competitive position. Bush did not want to conduct research just for the pursuit of knowledge he knew that it would lead to new products, practical usages and bolster our competitive position on the world stage — “New products and new processes do not appear full grown. They are founded on new principles and new conceptions, which in turn are painstakingly developed by researching the purest reals of science”. I read this report while I was in grad school and thinking about working in the public or private sector and I had this in mind while I was reading Mariana Mazzucato’s book The Entrepreneurial State.

Mazzucato reminds us of the importance of Vannevar Bush’s idea of government investment in R&D but she pushes beyond the notion of the government as a behind the scenes deep pocketed investor funding basic research but she advocates for governments to be recognized for their risk taking entrepreneurial market making activities they engage in. She provides some very interesting and compelling examples from domains such computing, Pharma, bio-tech, and clean energy to demonstrate that “innovations” from the private sector were really built on top of the hard work and investments done by and/or funded by the State, Mazzucato takes nothing away from the success of Apple but spends a chapter discussing the iPhone and how it was built based on technologies pioneered by the US government - see diagram below from The Entrepreneurial State.

Taking nothing away from Apple’s technical, design and business success Mazzucato demonstrate the State’s role in the critical underpinnings that make the iPhone possible.

The US government in particular seems to suffer from an inferiority complex and thus has a marketing problem. The State has ceded the narrative to others and allowed the tax payers to forget how some major technologies were developed. Mazzucato goes on to discuss fiscal/tax policies that could allow the government to become more of an active investor in technologies it develops to fund the next ventures and recoup some expenses and who knows, maybe have some money left over. She does have her critics for sure, but she also has supports on both ends of the political spectrum. It is definitely something to think about.

I have started a number of technology businesses over the years and must admit I continue to love the idea of the lone genius inventor out to change the world … maybe we have been taking too much credit?

Introducing Microservices into a Legacy Environment.

While currently no consensus exists on how to define microservices it’s generally agreed that they are an architectural pattern that is composed of loosely coupled, autonomous, fine-grained services that are independently deployable and communicate using a lightweight mechanism such as HTTP/REST.  Now is the time for companies -- particularly enterprises that need to make frequent changes to their systems and where time to market is paramount -- to be investigating how best to introduce microservices in their legacy environments if they expect to realize a digital transformation that drives tangible business results.

The benefits and potential hurdles associated with adopting microservices are well documented. On the plus side, the modular and independent nature of microservices enables improvements in efficiency, scalability, speed and flexibility. Detractors, however, frequently point to management and security challenges, especially when they pertain to customer-facing applications and services. 

Like virtually all technology decisions, it’s critical to balance risk with reward and, when it comes to microservices, embracing an evolutionary approach and process. After all, lessons can be learned from both success and failure, and the same is true for implementing microservices that can increase product and service quality, ensure systems are more resilient and secure, and drive revenue growth. In the first of this three-part series, I’m going to explain how business and technology leaders can smoothly and successfully introduce microservices in a legacy environment.

It’s all about the monkey

A key requirement of microservices design is to focus service boundaries around application business boundaries. A keen awareness and understanding of service and business boundaries helps right-size services and keeps technology professionals focused on doing one thing and doing it very well. 

In my experience, I’m finding that the larger the organization the greater value microservices architecture can deliver, but only if executed in a systematic, enterprise-wide fashion. Fortune 500 organizations tend to have a significant proliferation of legacy technologies and should strive to simplify deployment, along with applying continuous integration and delivery of microservices. All too often, enterprises focus their efforts on buying tools, implementing a small proof-of-concept or other “quick wins” that likely aren’t the most effective place to initiate microservices strategies.

Astro Teller, the “Captain of Google Moonshots” has a humorous anecdote about where to begin when solving a large and complex problem and advocates that companies should avoid allocating all of their resources on the easy stuff and instead start by addressing the hard problems; he calls it “tackling the monkey first.”  The monkey, when deploying microservices in a large, established environment, is understanding and decomposing the legacy systems.

Decompose the legacy environment by identifying seams

In the second part of this series I’ll cover domain-driven design (DDD), but for now it’s important to understand two concepts found in DDD: bounded contexts and domain models. 

Any problem domain is composed of a number of bounded contexts with models sitting inside them. The bounded contexts provide a level of protection and isolation of the models. In addition, the bounded context provides an interface to the model and controls what information is shared with other bounded contexts. For example, in an e-commerce application some of the bounded contexts may be ordering, pricing, or promotions.   

Years ago I enjoyed reading “Working Effectively with Legacy Code” by Michael Feathers. In his book, the author presented the idea of a seam as a way to identify portions of code that can be modified without affecting the rest of the code base. This notion of seams can be extended as a method to divide a monolithic system into bounded contexts from which services can be quickly and seamlessly created.  

Uncovering seams in applications and building bounded contexts is an important first step in breaking down the monolith. Seam identification can be accomplished by reviewing the current code base, interviewing domain experts, and understanding the organizational structure. A few suggestions:

• Review the current code base. When reviewing the current code base and any artifacts it’s critical to realize that this is only a starting point. The code is often redundant and difficult to understand. 

• Interview domain experts. This is a key step to learning where the seams are and identifying bounded contexts. Having domain experts that understand what the business should be doing not just what the system currently does is critically important.

• Understand the organizational structure – Often, organizational structure will provide clues to where the seams can be found.

Once bounded contexts are identified, along with the programming language and environment that support them, creating packages and sub-packages that contain these bounded contexts should closely follow. This approach will afford a careful analysis of package usage and dependencies, which are paramount to fully and quickly understanding and ensuring that testing and instrumenting code is being done properly.  In addition, there are some standard design patterns that should be followed:

•  Open Host Pattern - Exposing legacy systems via JSON/HTTP service.  Here the isolated legacy system is exposed through an API that returns JSON.

• Anti-Corruption Layer (ACL) Pattern – A translation layer or sometimes called bridge layer is built between the legacy environment and the microservices code.  This pattern can be effective for short durations but it can be costly to maintain over time. We have also called this layer “scaffolding” it’s needed during the transition but will be taken down after the job is done.

 That’s how microservices should be introduced in a legacy environment.

Read the second post in this series here