Showing posts from October, 2021

Cloud Strategy: All In or Total Portability

Organizations have two primary strategies when they move to the cloud. Prioritize time to market. Use the cloud provider's services as they were built without customization. Prioritize portability and capability. Focus on avoiding vendor locking by buying the best cloud-agnostic or building their own t meet their custom needs Every technical or platform decision needs to include your cloud strategy as one of its primary drivers.  Decisions that deviate from the standard should be considered technical debt to be revisited later. The cloud strategy is like any other PDCA . Select a strategy. Document the drivers for the decision.   Make the approach clear to the company.  Revisit  the decision on a regular basis to align with business needs The benefits of both approaches

Someone wants your software - Is it platform ready?

You created some piece of software that can be repurposed by you or by others.  Step back and think about how the system was built.  Do the design and data protection rules mean you have to run multiple single-tenant instances?  Is it built in a way you can securely add tenants into a multi-tenant system? Identity management, data security, load isolation, data isolation, log, and metric isolation, reporting controls, data exposure, and APIs are just some of the things that you need to review before signing up new consumers. Multi-tenant or Single-tenant The big push is to Software as a Service.  You stand up your platform in the cloud for use by other teams or organizations.  There are two main models for supporting multiple customers.  Muli-tenant: The customers all run within a shared environment.  The environment is coded to firewall off the different consumer groups to make it appear as if they are the only ones in the system. Multi-tenancy often must be suppor

Isolating Historical Data and Breaking Changes

Teams often run into situations where they have a data set that broke its compatibility at some period in time.  This often happens when you have historical data that came from a previous system.  We want the ability to combine that data in a way that consumers have to understand as little of that difference as possible.   The differences between historical and active data are essentially a major version, breaking change to the data. The two major versions  of the data can be isolated in their own raw storage area and then merged together in one of our consumer-driven  zones.  We can continue to support minor version producer schema changes as they occur in one of the raw streams.  Those changes would then be handled in the transformation tier into the conformed zone. We register and link the three data sets in our Data Governance Catalog. This lets us capture the data models while enforcing data change and compatibility rules. Disciplined organizations will also register the two trans

Capturing SDLC Swim Lane Identities and Roles

Identity and Permission inventories first step towards understanding your identity and permission exposure. We want to create a common understanding of the identities and roles used by our systems. Actors that reach out to other capabilities operate with an identity . Capabilities that are asked to do something on behalf of actors are configured to allow or disallow work requests based on the role that the Actor's identity has in the receiving system. Individual components may be operate as both Actors and Capabilities at different parts of their processing. The principal of least privilege says that tasks execute with the minimum permission to do the work request. The simplest way to do this to isolate each actor by giving them their own identities. Each system contacted by the actors maintains an identity/role map that describes the identity's permissions in the receiving system. The table at the right shows The iden

Capturing SDLC Swim Lane Configurations

Software systems have gotten more complicated with the introduction of microservices, SaaS/PaaS services, serverless compute, and other patterns. Those components must be managed, created, and integrated across multiple environments that make up the Software Development Life Cycle. This talk describes a method for documenting how the software is configured and how it can be reached across various environments. This is useful for: A common understanding of the environments Communication between teams. YouTube Video See how we can create an environments matrix  based on the simple web application shown below. The table in the video is flipped on its axis from the table below. It shows the properties across the top and the environments down the page.  The table below and above shows the environments across the top and the configuration information down the age.  The former works better when you have  a lot of environments.  The table on this page works better if you have  fe