The history of IT delivery  is the history of compromise.  Early systems were designed around technical limitations ("green screen' 32x80, reports with fixed 133 characters, no visuals, limited CPU/memory/storage), while later systems were still restricted by resource constraints (essentially pipe size) and cost controls.  The hardest thing for a technologist is understanding what the customer needs and knowing we can't deliver that.  These legacy solutions (often delivered through  anti-patterns) are a hurdle to digitization.

We are now in the age of the possible.  We can often deliver the customer what they truly need (another historical legacy constraints was users would ask for what they thought they could get, not what they needed).  It just can't all be done all at once.

This is where the "moving forward by thinking backwards" comes in.  The desired end state, although always changing, can be described - flexible, easy to change, easy to enhance, easy to maintain, robust, secure, transparent, ... All enterprises have similar end states.  

The methods of solving individual problems tend to work along a certain plane.  These are the requirements and these are the problems and these are the steps to resolution.  With "trajectory" thinking, we think of the end state and figure out how we align our solution with the desired end state.

By  describing the end state (a visoneering exercise), one can understand what it will take to get there.  The deliveries are not only related to solving the problem, but taking into account the end state and assuring deliveries take both into account.

Example: ATLaaS Security

Complex thinking is a work hazard when applying technology.  Technicians love to describe the minute details of the technolog; for that validates them as true technicians.  What gets lost is that the simpler the solution, the faster it gets developed and the easier it is to maintain. If a solution sounds too complex, it is.  

I once read a story (over 50 yeas ago in Reader's Digest) that reflects the point.  George Plimpton was interviewing the race car driver Jackie Stewart.  While conducting the interview, they came across a British tank unit performing maneuvers.  Plimpton had driven these exact tank during his military service and challenged Stewart to a race, It seems far fetched but the unit agreed to allow them to race (at that time Jackie Stewart was a national hero).  When Plimpton got in the tank, he verified on how everything worked, got his bearings, and was ready to race.  On your mark, get set, go.  And Jackie Stewart blows him away.  Plimpton asks Stewart how he did that.  Stewart replies, "I only asked one question.  How do you make this thing fly?". 

It is not how much you know, it is the outcome.  Things have to be focused on outcome, and that simplicity makes discussions of technology and its application simpler.

Example:  O365 email conversion

"Agility is the ability to adapt and respond to change … agile organizations view change as an opportunity, not a threat." - Jim Highsmith

There has never been a perfect system.  Even if a perfect system was delivered, at some point it would have to change.  Understanding change is essential.  

Have you ever sat in a requirements or design meeting where a question comes up where you can see nobody really knows the answer.  The first thing you should say to yourself is that this is one thing that we are going to have to make simple to change.  

In today's enterprises, designing for change is vital.  To design for change, you must understand change.  What makes systems hard to change and how can that be simplified.  

Once upon a time I was the technical architect  for a  large modernization project ($100M, 250 person project team).  The management team (of which I was a member), fired the consultant and decided to do the project in-house.  I knew I owned the resulting solution for the rest of my career and had to live with any complaints.  

The first thing I did was analyze all historical project information, change requests, annual changes, etc.  The goal was to try to figure out what types of changes needed to be made simple.  It turns out two types of change were most difficult - database and state.  

Database changes required an outside program to move data around, all interfaces to be reviewed, and considerable testing.  Database changes tend to be so difficult, programmers often "re-purpose" fields which leads to some data quality issues.  Any design should use  tactics that can eliminate these issues.  Example of Tax Filing

State changes are harder to understand, but easier to fix.  Historically there was a data field that kept state (where you were in the process) - Order received, shipped, delivered, bill sent, etc.  The problem of having state represented as a field is that if you want to change the process (add a new state), a very expensive impact analysis must occur.  How would programs react to the new value?  Would the new value "break" something?  This analysis not only took weeks, but the testing of all the potentially impacted programs made these changes horrific.  To achieve agility in state, a BPM engine was used to externalize process.  Example of Returns Processing - Exceptions.

Externalization (of security, process, rules engines) is a key concept in safely attaining agility.  Externalization facilitates business configuration.  "Software defined" configuration has been used for networks, infrastructure, etc.  Can it be used to configure the business?  Definition of The Right Strategy.  

Before deigning any system ask yourself how am I going to simply maintain this, what could change, and is there an opportunity to empower others to independently make the changes.

An appropriate use of technology is everyones responsiblity.  It is too important to leave in the hands of technicians. 

Every business is being challenged by technology.  Competitors and market forces can challenge even the most established enterprise through  superior use of technology. Technology is not enough; it is the appropriate use of technological capability.  

The FOMO effect with technology often results in a technology first, shiny object approach.  The implementation is often a chore to get new technology implemented and working.  

The Right Strategy is a short cut to understanding capabilities.  The tool concept simplifies what is meant by a capability. It is a component of tool (either business driven, technically driven).  Any user can describe what tool they need to achieve a task.  It is just a collection of re-usable capabilities (even I can describe the tool I need to perform brain surgery although you wouldn't want me to test it).   Capabilities can only be consumeed by a tool or a process.  Either they can be automated or augmented (think of AI).  The goal is to implement new capabilities in a reusable pattern rather than a technological exercise.  Example Blockchain vs Ledger.

Leveraging capabilities is not easy.  They are often "integrated" within commercial product sets.  Exposing these capabilities is a worthwhile opportunity, but care must be taken to not tightly couple them with what will become an outdated silo.  Example - Two approached to BPM.

Achieving a capability based approach is the goal (thinking backward).  The Product Approach to EA facilitates a capability model. Example of  EA Capability Model.

Example - Document Management

"Inside every large problem is a small problem struggling to get out" - Hoare's Law

Top-down vs bottoms-up desgin has been argued for decades. The vendor on my first major modernization (mid-80s) was all about bottoms up.  They started with technical stack first, then data field and table definitions, and built up to applciations.  In the 80s this worked becasue there were limited technical stacks to build upon.  Consumption was on a green screen of only characters. Processes were hidden within a series of batch programs that manipulated data.  Using Hoare's Law (above), work was broken down into "sub-systems" where a bottom-up approach could be employed.  The result was the EA anti-pattern - the Silo.  This is not just history.  Many data-driven designs have the same flaw.  The underlying problem is the late "binding" to context.  The pieces are created before they understand how they have to be composed to solve business problems.  The solutions lack context.

The top-down approach is context and consumer-centric.  The top-down approach of The Right Strategy is very simple in that there are only two business implementations - a Tool or a Process.  A tool is a collection of capabilities to achieve a goal.  Likewise a process achieves a business outcome by a combination of automations and user tasks.  Automations are implemented through a series of business capabilities.  Tasks are achieved through tools.  

The focus on business capabilities avoids the traditional issue with top down design - "death by decomposition".   This occurs when continually breaking down components goes too far.  This  results in an unmanageable number of components.  It often results  in components that repeatedly must be assembled to create business capabilities. It limits innovation because replacement requires testing of both the capability and its non-standard implementations.   Right sizing requires a business focus. 

The top-down approach is the dominant approach in the industry today.  It can be very successful if infused with a strict business focus.

Example The Business Component

One issue in transforming an organization with technology is how can this be achieved and not result in operational and support complications.

When introducing new technology, even in pilot mode, future reuse must be considered.  The pilot has to result in business capabilies that can be continuously leveraged.  If the pilot is only focused on "getting it to work" the result will undoubtedly have to be revisited. This will slow adoption and the pilot will become a Shiny Object Silo.  

A business capability focus on new technology establishes a standard that the pilot must observe.  The pilot will have new requirements around integration.  The pilot must deliver functionality that is easily leveraged in a business context (by process, tool, or composed business capability).  Standardization simplifies support and innovation.

If there is no standard, there can be no optimization.  There are too many outliers (non standard solutions).  Everything becomes an exception.  Enforcing standardized patterns simplifies optimization.  

Optimization is not only about operational efficiency.  It is about making optimal use of all the assets of an organization.  This is transformation. Standardized components can be optimized into business tools that enable non-technical staff to configure the business.

Example Tabsets and BABE

"We owe the origin and development of human society and, consequently, of culture and civilization, to the fact that work performed under the division of labor is more productive than when performed in isolation."  - Ludwig von Mises

There is a significant difference between Modernization and Transformation. Modernization is a technical exercise; Transformation is organizational journey.  Transformation is not just automation or AI doing things.  It is about how technology let's the true business experts execute their vision.  The biggest difference is not between workers and automation, but between the tasks IT does and what the business is empowered to do with technology.

The analogy is that traditionally we were building buildings and now we are building cruise ships.  As stated before, the design anti-patterns result in Silos (of information, UI, skills, security, etc).  These Silos are something a consumer "had to go to".  The consumers were traversing silo by silo.  These silos were build to the same basic blueprint ("one of the anti-patters and traditional project management).  

The alternate analogy is that we are now building boats.  They are meant to go places.  They are meant to navigate the future.  This future entails a different division of work.  Vendors become suppliers (of capability).  IT builds the boat to the business specifications but with knowledge that the customer must "sail" the boat.  Business users are empowered to map out the boats path, steer the boat, run the engine room, etc.  What is being build is meant to empower the business. The goal is to allow the organization to leverage every asset  optimally.  Lastly external customers are the passengers to which the business serves.  

Empowerment for specific technologies can be accelerated through a Center of Excellence/Communities of Practice approach. The Center of Excellence is the technical Product Owner of the technology.  It establishes and facilitates the usage and integration of the technology.  These best practices are then handed over to the Communities of Practice to leverage.  The Communities not only become a customer of the COE, but their major contributor because they drive the product roadmap.  The Communities of Practice develop assets in the new technology and participate in the new SDLC as defined by the COE.  The COE/COP approach is extremely successful when the technology has value across multiple business units (AI, Analytics, BPM, etc.).

An organization's digital transformation can best be evaluated by looking at how it leverages all its assets (people, technology, processes, things, etc.).

Example Employee Empowerment

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.” - George Bernard Shaw

This pillar is not original.  Once I became a Director, my organization had me take several training sessions.  One was on being an unreasonable man.  At some point you will have to challenge your team (organization), by telling them what they are proposing is not good enough.  This is the manager as challenger philosophy.

It is not enough to be unreasonable.  There must be reasons.  In this methodology it is because one of the other pillars is being violated.  It often is that what is being proposed is too complex, an inappropriate amount of work, requires heroic programming,  has too many moving pieces, or is just too difficult to maintain.  A unreasonable man is worried about easing the next decision. 

Example SWAN and Cross Account Delegation