Building a Platform Strategy

Building a platform strategy in a medical device company brings a number of communication, alignment and orchestration challenges. To tackle these challenges, Digital Diagnostics engineers plan on breaking down, organizing and addressing software architectural concerns that affect our organization and system.

As we endeavor to build a platform strategy, we’ll start by addressing software architectural concern #1: how are the biggest, top-most system design concerns able to be broken down? It begins by defining and typing services that are composed within the system. Are these services to be transactional or analytical? Are the services producers of data or consumers? By using these two characteristics to type services there begins an initial organization with the system.

Transactional services handle operational data, work with smaller amounts of data relative to analytics systems, have faster processing speed requirements and require both read and write operations.

Analytical services handle historical data, work with larger amounts of data, have slower processing speed requirements and perform only read operations.

The next fundamental question we’ll ask ourselves is, Is there a need for core services? Core services are services shared across multiple domains within the company. If the answer is yes, then it’s the start of a platform and we can begin to ask ourselves how this platform will be structured and how will services within the platform communicate.

• Should services communicate with one another by making API calls?
• Should services communicate by producing and consuming data?

Next up: we’ll decide the approach we’ll take on the continuum between a centralized and de-centralized approach to developing services.

There is no right answer between a centralized or de-centralized approach to building services. It depends on the volume of resources invested into a platform build and the trade off when delivering product for commercial needs.

A decentralized approach to resourcing service development has the following pros and cons:

Pros:

• Faster speed to market
• Less single points of failure

Cons:

• More cost to maintain
• Less control over standards

A centralized approach to resourcing service development has the following pros and cons:

Pros:

• More control over standards
• Cheaper cost to maintain

Cons:

• “Not invented here” syndrome
• One size doesn’t fit all

With some patterns established and a style to service orientated architecture, we’ll next catalog by collecting the following properties for each service:

These properties aim first to inventory existing and proposed services for the purpose of building awareness of needs and intents. This service catalog is then used to prioritize and resource use cases to address customer and operational needs. With an inventory in place, we’ll look to spell out how services can interoperate using enterprise integration patterns.

Maintenance of any piece of software is typically 90% of the total cost of ownership. With such a high burden on the cost of maintenance over time, its very typical that change management drives software design. Brittle software design slows the velocity of teams over time. Clean software design does not impede the velocity of the teams over time. To address the concern of good change management – the ability to receive and solve for changing business requirements – an architecture enabler that we’ll employ is to reduce or eliminate coupling between teams, services. Two anti-patterns that are important to avoid: two teams/apps/services sharing the same database tables, rows and columns or sharing a mutable, loosely versioned API. With either approach the velocity of teams can significantly be impeded due to the high cost of communication to make any changes and this is something we’ll want to avoid.

After we have established the patterns of communications between services to enable high performing service development and deployment, based on loose coupling between teams, we’ll need a means to establish payload contracts and communicate those contracts between services and teams.

For contracts, we’ll use JSON Schemas that define metadata. Here is a basic example:

With contracts defined, we will then create the culture and discipline to ensure changes to contracts are versioned and communicated amongst teams.

Lastly, to get the team engaged in defining and owning the architecture of our system, we’ll define our software architectural principles to align, establish a rhythm of fun knowledge sharing “get togethers” and create a forum of software architecture and design best practices to be discussed, agreed upon and put into action.