Unlike diamonds, information systems (IS) are not forever. As a company evolves, its IS evolves too. This evolution is induced by a company’s business and organizational transformations, regulation modifications and/or technical revolutions. In this Lego computing age, evolving an information system often means aggregating existing brick products instead of building them to create value.

Plug and play brick products, opposed to conventional products, are beneficial because they reduce integration complexity, cost, and time to market. In this article we’ll show you why a company should shift to integrating brick products and how to evaluate such products with a 10 question cheat sheet.

The Composite Enterprise

When a company’s IS evolves, two major concerns regarding this evolution must be:

• Can this evolution be handled by updating current IS components?
• Should new components be developed or assembled?

Asking these two questions enables the creation of the composite enterprise.

Concern #1: Evolving is not always updating

The challenge with Postfix, or with any piece of software, is to update software without introducing problems.
Wietse_Venema

Simply updating existing IS can be a terrible idea

When updating an IS, especially a huge and old monolith, companies usually update their existing components to fulfill new needs. But, sometimes, this can be a terrible idea.

• New projects may involve totally new functionalities far from what is already handled by present components. Adding this new functionality to an existing component which was absolutely not built to handle such things is a bad design choice.
• Adding new functionalities to an already hypertrophied monolith makes it less and less maintainable.
• Why evolve obsolete components using obsolete technology nobody wants to work on?

Updating components this way may lead to a total failure for the project as implementing these new functionalities can be difficult, long and expensive. The result may also not meet expectations and have unexpected side effects. It may even hinder the company as this project can increase technical debt and make company’s IS less attractive, making it difficult to hire people to work on it.

Updating is not the only option

Companies that work with the same software for years tend to forget that updating existing IS components is not the only option.

Tabula rasa
The mind is a blank and empty slate before receiving outside impressions

A new project may be the ideal time to think out of the box and fulfill a company’s new need by replacing certain parts of your IS with new ones, or by using totally new components. Integrating new brick products can help realize a project in a more easy, fast and inexpensive way, and also improve a company’s IS by reducing technical debt and making it more appealing.

Concern #2: Evolving is not always creating from scratch

The standard library saves programmers from having to reinvent the wheel.
Bjarne Stroustrup

When a company wants to replace a software component or needs a new one to fulfill new needs, the question is: will the company fully create it on its own or rely on other product(s)?

The answer to this question lies with two principles:

• Do not reinvent the wheel
• Focus on creating value to set the company apart from competitors

Speaking of wheel, the car industry is a good example of this strategy. Nowadays when creating a new car model, a manufacturing company will focus on either design, global cost, or efficiency. This company will rely on partners for parts such as wheels, windscreen wipers, brake pads, or even the engine.

Wisely aggregating products into a single model is what sets the car apart from its competitors — enabling producers to maximize on a core competency. The philosophy of aggregation is just as important in tech, as it enables the composite enterprise.

The composite enterprise in the Lego computing age

Integrating IS components is not new

For decades companies have integrated external products into their IS, but these products were sluggish, preventing the composite enterprise to flourish. Take for example the installation of a CRM system before the dawn of web APIs:

• On premise: these components had to be installed and run on the company’s local infrastructure
• Hard to integrate with other products: they were not often provided with easy to use connectors
• Poorly scalable: because of licensing or complex installation procedures
• A human resource nightmare: it’s not always easy to find people with the required skills to handle this complexity

All this made these products quite expensive and hard to replace — therefore holding back the composite enterprise.

Brick products

Fortunately, the IT world has evolved — APIs, containers, microservices, IaaS, PaaS, SaaS — all these technologies are enabling the creation of brick products and the Lego computing age.

In an ideal scenario, a brick product is a replaceable product that will integrate easily and seamlessly within a company’s existing information system. Example products include:

• An address validation API
• A SaaS CRM
• A managed database service

A brick product can be provided by external parties or built by the company itself. These products can be used alone or combined to create a new product which can be turned into a brick product itself, just like Lego bricks.

Nowadays, these brick products allow the composite digital enterprise to finally emerge. Every company can now easily evolve at light speed to surpass its competitors under the condition of choosing and aggregating brick products wisely.

Evaluating a brick product in 10 questions

One key factor in this race is the capability to choose bricks wisely. So, we have prepared ten questions to help in choosing a brick product.

Question #1: Does the new product meet my company’s functional or technical requirements?

Obviously, a brick component must meet your company’s functional or technical requirements. A deep knowledge of company needs and brick product capabilities is necessary to ensure that the chosen product will match these needs. It’s particularly critical when choosing managed services on platforms such as AWS, where one need can be fulfilled by many different solutions.

The key point is that the chosen product must not bend to the company’s need until it breaks.
Some companies, especially big ones, tend to think “that product is good but we have very specific needs different from every other company in the world”. This may be true, but in most cases it’s only a matter of adapting to the product.

If integrations for brick products are highly customized (for the great initial satisfaction of integrators), this can easily lead to bloat, and unusable, impossible to update software. That is why an inevitable amount of standardization is necessary on both sides.

Question #2: How can the new product be deployed?

Nowadays software products can be deployed in many different ways.Tthe most common are:

• On premise: Installed on the company’s infrastructures
• IaaS/PaaS: Installed on an external infrastructure offered by a third party
• SaaS: Provided and managed by a third party

In many cases it’s far better to have a managed black box which is monitored, updated, and scaled seamlessly without doing anything. It may even be a cheaper alternative.

Location vs regulations

Cloud solutions (IaaS/PaaS/SaaS) run on data centers scattered all over the world. As each country has different regulations on data, it’s a good idea to check that these products are not inconsistent with any country regulations you may have ties to.

Company’s infrastructures vs provider’s infrastructures

Cloud solutions are very attractive, but in certain cases the new product needs to communicate with or be accessed by other existing components on other clouds or existing infrastructure. Security and performance may be an issue then. Some IaaS platforms create direct network links between their data center and the company data center.

Question #3: What does the new product do with the company’s data?

Beyond regulations induced by data center location, the product provider may also have specific ways of dealing with the data handled by its product that may be inconsistent with your company’s country regulations or ways of thinking. Some common concerns are:

• Does the service provider use the product’s data for other purposes?
• Does the product’s data still belong to the company?
• Can the product’s data can be exported?

Question #4: Does the new product provide connectors? (APIs?)

A brick product is meant to be integrated in an existing IS. A connector is an interface that allows the product to send and retrieve data to other components.

Anyone who doesn’t do this will be fired. Thank you; have a nice day!
Jeff Bezos, Amazon CEO about interfaces

Nowadays this usually means API, but that’s not the only way to integrate a new component with an IS. Whatever the means, a new product MUST provide connectors to ensure interoperability. Providing a standard connector (such as a true REST API) will make the integration easier.

Even if the product comes with a white label web site or mobile application that can fit the company’s primary needs, especially with a really short time to market, providing API connectors ensure that the product can be integrated in any thinkable way.

Question #5: Are the provided connectors usable?

If a brick product provides connectors, they MUST be usable from the company’s context:

• Are these connectors standards? Example: A HTTP REST API vs a proprietary protocol.
• Are these connectors documented? Example: API interface description, code snippets, use cases.
• If an SDK is provided, is the language used by the company covered?
• Is there a connector to handle batch operations? This is useful when dealing with large amounts of data at the same time.

Question #6: How does the new product handle security?

Like any software a company would create, a brick product MUST follow the company’s security rules, and, as the product may be provided by a third party, some new rules may also be necessary. Some of these new security concerns are:

• Who can access the product’s data or infrastructures?
• Is the data encrypted?
• How is the product’s access protected?
• Do the products provide an identity and access management system?
• Can this security system interface with the company’s security system?

Question #7: Does the new product provide administration tools?

Depending on the product and how the product is deployed, the need for administration tools will vary. But whatever the deployment mode, all facets of a brick product’s administration tools MUST be considered like any other product; especially regarding:

• Technical and functional requirements
• Connectors
• Security
• Usability

Question #8: How does the product’s provider handle updates?

Like any software, a brick product will inevitably be updated by its provider to bring new functionalities, remove existing ones or only update internal components (like a database for example).

Depending on update’s content, the schedule proposed by the provider may have more or less impact. If a technical update will be easy to handle, a major functionality or API interface modifications will impact all the company’s components using this brick product. Therefore having a clear roadmap and large schedule will help to handle this updates easily.

The effort needed to install the updated product will be more or less significant depending on deployment method. On SaaS, the company will have nothing to do, but on premise, the company will probably have to do all the update by herself.

Question #9: What is the pricing policy?

Pricing is definitely not a new concern when choosing a product. Though new ways of providing products often bring novel ways of monetization — Freemium, revenue share, etc. — the key principles regarding pricing are still the same:

• Evaluate the pricing for current activity
• Make projections matching company’s business perspective to avoid bad surprise

Question 10: What about the product’s continuity?

A brick product is a replaceable product. Unlike diamonds, online products and providers are not forever. The best way to combat this transient nature is to adopt products that adhere to transparent deprecation policies, like the Google Cloud Platform:

Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement[…]
Google Cloud Platform terms of service section 7

Taking a look at how the product provider has handled past deprecations is a good indicator. But no one can foretell the future, and even well-adopted technologies change (cf. Parse example), therefore the product MUST propose export capabilities (at least for critical data) from the start.

Conclusion:

The composite enterprise is not a new concept, but in this Lego computing age it can be achieved more easily and in a more versatile way as replaceable brick products are easily found and integrated in existing IS.

Choosing a brick product is not fundamentally different than choosing a product ten years ago, but new considerations have arisen and must be taken in consideration — especially data privacy and reversibility.

How has your company adapted to the Lego computing age? Tell us below!