Modern IT Architecture in One Word: Shared
Social, mobile, analytics and cloud drive today’s business. Social involves shared consciousness. Mobile involves shared services provided to individual devices. Analytics are run on data shared from multiple sources. And cloud deals with the sharing of resources, such as compute, storage, platform, software and so forth.
by Bob Donnelly
The common theme, of course, is sharing — and this shift toward sharing is causing IT architects to look at systems in new ways.
We’ve already touched on several different meanings of sharing. People voluntarily share things online. Some companies actively mine data based on information consciously shared or via actions such as buying something, typing something into a search engine, or visiting a website. While analytics are based on data “shared” or gathered from multiple sources, this does not necessarily involve a shared component in the architecture.
Shared source code, or binaries, is another context. Architecture is influenced by the tools available to implement it. Many projects use trade studies to consider the appropriate tools, and reusing existing tools that fit saves time versus creating something new. Shared can mean open source, inner source (shared source among a closed community), closed source development libraries, or licensed commercial software.
While this context of sharing influences architecture, the resulting architecture stack may not have any external dependencies. You may run a database used by many others, but it can be a separate instance run on your hardware. You may utilize user interface libraries used by many others, but they are compiled into your executable code.
So, how do we define a truly shared architecture? It’s one where one or more layers of the architecture are shared with others during runtime. Certainly, Anything as a Service (XaaS) involves using shared resources for certain layers of the architecture. Hardware and virtualization layers are provided in Infrastructure as a Service (IaaS). Platform as a Service (PaaS) and Software as a Service (SaaS) provide application hosting or applications themselves. Boundaries between the shared resource and the customer-specific application are well defined and may be formalized in an SLA.
As a system/software architect dealing with system-of-systems-level integration, I see sharing that does not have as clean a boundary or interface. Instead of a well-defined hosting environment, services are truly shared among multiple stakeholders.
The next step
Recently, there has been a marked change in approach as we transition from services moving data between systems to systems truly sharing the same data services. Let me explain.
Previously, in a layered architecture, a single supplier would provide every layer in the entire stack. Systems may have run a common service that moved data, but these focused on exchanges between systems. Once data hit a particular system, it would be independently stored, manipulated and viewed.
Recently, there has emerged a concept of storing data once for all “systems” to access. A common data store is now fast enough so that data can be created, read, updated and deleted (CRUD) by multiple systems at once and still meet performance requirements. If there is any “distance” (network latency or limited bandwidth) between data users, a local copy may be needed, but systems on a fast, local network can share this one store. The net result is a migration from independent, vertical stacks, each acting as its own system, to shared, horizontal services that enable each “system” to concentrate on its independent function. The concept of “system” begins to morph.
Yes, there is work to enable this: agreeing on a common data model; defining an API that meets the combined access needs; designing the data services to meet the combined performance needs. Potential gains include reduction in hardware (since one shared data store replaces many) and enhanced capabilities from having the aggregate data (versus a subset) to work from.
Sharing is not always easy
Getting varied, interested parties to agree on the form of these shared services requires combining technical skill with organizational and leadership skills. Aligning product release schedules is a challenge, as is handling legacy integration and interoperability. In short, success depends on agreeing to shared requirements, shared schedules and shared technical solutions.
The system of systems transitions into a system of services. Services replace systems as the primary component. A given function becomes an application running on top of these services versus a system with its own vertical stack. Companies such as CSC morph from system integrators to service integrators.
We’ve looked at various meanings of sharing: an XaaS model with a defined boundary involving payment for services; shared contribution to a data stream; shared source through both open and inner sourcing; shared requirements implemented in common services used by multiple users to implement various functions.
A modern architecture has some combination of these features. “Modern” is possibly best defined by what it is not — namely, a full stack, or “system,” owned by one provider.
IT architects need to figure out how to create shared ingredients that can be combined to meet different technical requirements. These become the basis of a microservice architecture. Over time, single ingredients may be swapped to insert new technology and improve performance. This may be harder than creating a single product, but it enables the provider to keep fewer solutions on its shelf, meet customer needs quickly, and reduce costs across product life cycles.
BOB DONNELLY is a distinguished engineer at CSC.