Posts

Showing posts from October, 2021

SEP and its evil twin Someone Else's Problem

Image
Someone Else's Problem  is a term that declares that some work  out of our  control or scope. Sometimes we declare someone else's problem  so that we don't have to take any action. I n the best situations, we evaluate and declare SEP so that we can focus on our core needs. Maintaining focus and scope control is one of the hardest things to do when creating new software systems or implementing various types of programs.  Every decision or new requirement spiders off to touch other requirements that demand other decisions.   Some of those touchpoints belong to other teams.  This means your success is dependent on the actions of those other teams with other priorities. Sometimes that means you have to get heavily involved with the other team's activities to ensure that they do what you need.  This takes focus away from activities that are truly within your charter. SEP as avoidance One of the downsides of SEP is ho

Selecting a SaaS platform is about more than business requirements

Image
Software as a Service can be an equalizer, giving organizations access to best-of-breed capabilities with lower entry costs than custom-built or self-managed services.  Product evaluation involves business requirements and non-technical and technical Non Functional Requirements.   The following are part of my list of mandatory NFRs for a modern internet-connected SaaS product. All of these are discussed in more detail in the video. Video Control and Data Plane Platform Control Plane  Software management functionality used by the SaaS vendor must be isolated from the Tenant control and data plane. It must not overlap functionality that is delegated to the tenant. This plane should not have access to business API or data. It should be easy to block access from the public internet. Tenant Control Plane  Softw

Cloud Strategy: All In or Total Portability

Image
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?

Image
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

Image
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

Image
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

Image
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