Posts

Showing posts with the label Architecture

I tried to plant something in a garden....

Image
I tried to plant something in an enterprise garden.  The garden was actually be a graveyard of bad decisions. First Version. I tried to plant something in an enterprise garden. It turned out that it was actually a graveyard of bad decisions. Revision History This page is subject to revision based on future input. Created 2025/04 Updated 2025/07  

Bug for Bug Compatability in IT systems.

Image
A new system that behaves exactly like the existing system in order to allay fears and, retain all the existing interfaces, data meanings, and testing approaches. The new system's business behavior is identical and all interfaces are the same or easily adaptable. That compatibility extends to all the idiosyncracies of the previous system including all the workarounds that were put in to support other systems or rules that may or may not still be valid. This is a design of least surprise. Video https://youtu.be/npcuWeKnkj0 Slides Speaker notes to be added Video Revision History Created 2023 02

The difference between Information and Data

Image
Data is a collection of attributes. Information is data that is invested in or drives or has meaning within some type of business or another process.  The same data can represent or have different information contained within the scope of different bounded contexts.  My target here is operational systems where we partition information within business operational contexts. Analytical stores are a bit of a different beast because they tend to be large collections of data that are converted into information through data aggregation and promotion. What is the difference between Information and Data?  Why do we call it Information Science but a Data Lake? I have no idea why they call it the last two but I'm going to use those two labels to bolster my case. Video Slides used in the Video Speaker's notes are to be added at a future date. Revision History Created 2023 02

Surfacing things we know nothing about - What we know vs What we need to know

Image
Every nontrivial problem space consists of a multitude of issues, constraints, data points, and information-driven decisions. We try and understand or manage these conditions and variables based on our risk assessments which are biased by how well they are understood.  This effort is a continual iteration where we strive to collect and classify issues and variables as we run across them.  Some of these problems are very complex or outside our sphere of experience which forces us to pull in other disciplines or people with other experiences that may be able to identify additional requirements and constraints, unknowns, and uncertainties.  This article is in a draft and is subject to revision. I first heard the known-knowns   known-unknowns  and unknown-unknowns when a technocrat gave a speech over a decade ago.  I had no idea what they were talking about and later learned it was a decision-making and political modeling tool  https://en.wikipedia.org/wik...

A sordid tale of customer identifiers - the complexity of knowing when we know

Image
Customer identifiers are the keys we use to bind different bits of information together that we believe represent the same person. This can be more complex than it sounds when you take into account the changing amount of what we know, corporate acquisitions, and partner company interactions. Video Presentation Content Speaker's notes to be added at some future date. A corporation, with divisions that each have apps and with partners. The corporation runs with a single id per person and handles any merge or separation actions by updating all parties. Conway's law: Architecture and communication paths align with organizational structure. Every team does their own thing. Division IDs are bound to the corporate ID at the corporate level. Corporate IDs are bound to the division at the division level.   The corporation creates link ids there shared with the other orgs. The other orgs create link ids and share with the parent corporation.

Quality is day 2 - the day that never comes

Image
Quality has to be baked into the decision-making process from the beginning of any effort. We often talk a good game about making sure we improve the quality of a product or process at "some time in the future" or "in the 2nd release". We hear this a lot in the crunch period at the end of a project. The date or some features trump repeatable process or quality efforts.  The next iteration is filled with "must-have features".  Day 2 turns out to always be the next release, next quarter, or never. Baking corner cutting into the process Some groups just own that they will produce junk and build stabilization sprints  and quality increments  into their process. They schedule specific periods for additional testing and QC.  I've seen this work and I've seen it become a major anti-pattern where teams get even sloppier because they know there is a quality improvement phase. Immediate payof...

What are we running - API changes expressed as versions

Image
What API version is out there and how do we know it? The software world is continually moving along the path to more API-driven solutions in an attempt to break down monolithic software systems into more manageable size pieces.  We stitch together business processes with a collection of synchronous API endpoints, asynchronous messages, and massive event streams.  Every one of these connection points is a data and behavior contract that can be changed every time one of these endpoints is updated or upgraded.  Today's agile means that the individual services change often and at a rate decoupled from the API consumers.  We need to apply software engineering discipline to capture the changes and make it possible for our consumers to know which version they are talking to. Video Part 1 Change Types and Scale, Synchronous/Asynchronous APIs, Design Time vs Run time Considerations Part 2 Run Time versioning options for consumers and operations ...

Four faces of software reuse - Greatest strength is its greatest weakness

Image
We have four major patterns for reusing software and code. They each have their own advantages and disadvantages. This will be another demonstration of how an approach's greatest strength can also be a weakness of that approach. We will cover copy/paste, shared library, mono-repo internal library, and shared services. Today's pattern is tomorrow's anti-pattern.

A Software Architecture's Greatest Strength is Its' Greatest Weakness

Image
An approach's greatest strength is also often its greatest weakness.  You see this in Software Designs or Software Architecture.  We design something to be optimized around a set of needs, business functionality, ease of development, ease of maintenance, data integrity, performance.  Those decisions create their own problem.  We design and build systems optimizing our design around delivery capability, technology, NFRs, and business functions. Those designs and systems architectures take into account the best practices at that time . Those best practices sometimes come from other companies with different priorities and skillsets. The great strengths of your present-day designs will make up a good percentage of the future weaknesses. This should not be a surprise. We design around what we know now and around the technology available at that time.   Your successors will toss your design in the future when the strengths of the current approach become the thi...

Associating Personas - identifying when two "people" are the same person

Image
Identifying the "same person" when they exist in multiple affiliates or multiple contact channels can be messy with a set of tradeoffs. People show up or interact with organizations with different personas. They may be customers or incident reporters or marketing contacts or someone who just happens to make an inquiry. Even customers / registered people may exist as more than one person because of mergers, identity changes personal choice, or system errors. The speaker notes below represent a subset of the comments in the video. Video Associating Personas - Images Organizations make people create accounts in order to bind those people to permissions and preferences. Accounts may provide traceability from account to person but they often don't provide the only link to that person.  People can create multiple accounts for various purposes. This means that an account may be bound to a ...

Customers, Leads and Prospects are different levels of info trust

Image
Companies and organizations deal with people. Sometimes they are highly confident of the person's identity or the fact that it is the same person they dealt with in the past. Sometimes they are highly confident of a reliable identity when it turns out they are actually confident in the account's identity. Other times they have information that would never meet a legal bar. Those types of identities are good enough for marketing or sales or preferences but not good enough for legal documents or other use cases. Video The video goes into more detail than the speaker notes in the slides section. Presentation Content Organizations have all kinds of different contacts with individuals and other organizations. Our confidence in knowing those individuals ranges from anonymous to highly confident.

Protecting systems for different size disasters

Image
There is a lot of complexity in hardening IT systems to survive different types of disasters. They balance user experience, cost, complexity, and risk tolerance. Which strategies might work best? Talking in metaphors: A major disaster where a lot of other people are impacted, a storm with essentially a transient effect, or a self-induced fire where we ourselves accidentally burned a room or a whole building. This blog article exists to provide static images of the slides used in the presentation Video Presentation Slides  What are you afraid of?