The IT industry is founded on precision. It is based on coding and scripting where even the slightest change can cause undesirable results.  Yet when we talk about technology we get very sloppy.  Often the definition of things are imposed by vendors or others who have an agenda.  

The example - Data vs Information 

Data is just discrete, independent values.  It can mean anything.  A birth date is just a date until it has context.  Information is data in a business context (my precise definition).  We often have too much data and no information.  

This was drilled into me when we were designing our first composite graphical user interface. As part of requirements, I was allowed to monitor a customer service representative in  our call center.  The experience changed my perspective forever.  I would listen to the customer question and watch the rep navigate to the “answer”.  Having designed and worked on almost every system in the department, I thought I knew the best way to get the  answer.  I was shocked at the way  the rep navigated our applications.  They went to systems I knew were less reliable (either  through  a lack of cleansing  or a limited update cadence). They  eventually answered the customer question but it took considerable time and effort. I would also classify the answer as incomplete.  There were several observations:

1. The way  our systems were designed (Silos - Shadows - Silver Bullets - Shiny Objects) forced the rep to consolidate the data into  information on the  fly.  The good news was we had all the data, the band news we had no appropriate information. 

2. Even though the reps were trained in “best” practices, over time they developed their own shortcuts/preferences. Users had to go to the data system by system, rather than the information coming to them. This resulted in an inconsistency in service.  

3. Many of the systems accessed were well developed with state-of-the-art technology and methods, yet they did not meet the organization's needs. My entire personal value system of what was good work was challenged. 

This was the initial gestation of the Right Strategy.  The Right Strategy is an informational approach to design. 

When someone tells me they are data driven, the hairs stand up on the  back of my neck.  I know what they think they are getting - informed decision making.  I once was told that global warming was wrong because on a particular day it was cold out.  Whether global warming is true or not, that was an example of data driven decision making.  What it needed was context.  Is it cold relative to known history?  What are the  trends around temperature?  “Data is the new oil, in  that it has to be refined to have any value” (Jim Lieb).

So why in an industry built on precision are we so sloppy  with critical definitions?  

The foundation of the Right Strategy is based on a very precise definition of the Tool.

Tool is another term whose precision has been warped.  What is a “tool”?  In the Right Strategy the definition is very precise, it  is a collection of capabilities that facilitate a successful business outcome. The better the tool the better the outcome.  

In writing the book that this website is based on, I asked AI to rewrite my synopsis in simple terms.  AI misinterpreted completely.  It  said that CRMs and ERPs were examples of  tools.  At best they are containers of capabilities that  can be used in tools.  At worst they are another navigable silo (actually  silver bullet).  Capabilities are the focus, how they are delivered and implemented is of secondary  importance. (Solutions (CRM, HR, ERP, etc.) and products (O365 which really  is a collection of Collaboration capabilities) are often misstated as tools).  

A precise definition of a tool and its relationships to outcomes is the foundation of the Right Strategy.

Could you perform brain surgery if you had a precise tool?  Probably yes (although maybe there are better options).  

The capabilities a brain surgery  are easily understood - simple UI, robotic surgeon, imaging, monitoring, AI to understand the problem in relation to every similar surgery  ever done or thought of, a learning engine, etc.  

What would it require to improve the tool?  Always the same  thing - the integration of new capabilities or enhancement to existing capabilities. 

The more understood the specific problem (additional context what type of brain surgery, where in the brain,.. ) leads to better and more precise tools.  Tools allow continuous  improvement.

All people are  problem solvers, so  they  inherently  understand  tools and capabilities, facilitating IT/business/customer communication. 

Tools simplify work (training) and provide better, more consistent service.

The origin story of the Tools can found under Example of the Right Strategy - Tabsets/BABE. 

If all tools are made up of cohesive capabilities, then building any  tool is an exercise in integration (Example Tabset/BABE).  The value of inclusive, job specific tools has been well proven.  The Bloomberg Terminal  is a  great example and made billions.

The easiest tool to talk about in a customer UI.  Since its intended consumer  is a person it  has visual components.  UI design focuses on real estate and navigation.  One of the goals is  to make the UI “intuitive” so  that the user does not require extensive training.  This  is critical when the consumer is a web customer, but an internal user often requires a much more powerful UI.  Internal users resolve complicated issues.  They traditionally have access to capabilities that external customers shouldn’t (search is the prime example, external customers context is always their own information).  

The channel and the customer define the tool.  For example, a customer paper bill is a tool.  It encapsulates potentially many capabilities (backend information from several sources, information from the  billing  system , payment options, even a QR code to an application to resolve the issue).  

Tools and tool strategy will always have a consumer/channel component (Enterprise Architecture).

Tool design is often not the focus for any business. Tools are by-products of projects. Projects focus on functionality, not sustainability or extensibility.   The trend to improve all consumer experience (XCX, UX, CX, ...) is making progress, but because they are general purpose, they face common issues with security, support, and enhancement.  

A tool is an advanced user experience that is focused on a particular context and outcome (brain surgery).

Once a decision is made to make tools, there are certain prototypes to be considered.  For a consumer UI the  first decision is on the type of overall navigation.  Is it a wizard?  Is it  something else - like a tabset?  

A wizard has a defined path through its navigation; it gathers data along the way and has an outcome. If the steps are well known, a wizard may  be the answer.  Wizard are used for  web filing applications (and even eCommerce). They offer an optimized path to gather the  information for processing.  Some capabilities can  be  reused (electronic signature, review, etc.) for all filings.  The pages didn’t have to look like the forms; they just had to capture the data in the simplest way.   The pages were just UI objects that were written for easy integration.  The key here is to develop UI objects (in this case pages)  that encapsulate functionality and can be developed and integrated independently.  This standardization allowed us  to develop 35  web filing applications in the  first year.

A tabset metaphor was used for the more complicated tools required by our internal users.  Our customers wanted to have the capability to navigate around in the tool "as they  preferred".  The primary UI objects were tabs - pages.  The navigation was handled by another set of UI objects that handled the establishment of tabset context.  This included search (which resulted in a user, order, filing, etc. context) or accepting a credential with context (workitem, user).  All tools work within the context of the problem they  are solving.  Because of the standardization and reusability of pages, a drag-and-drop configuration tool was built that allowed the business to configure their own tools from existing pages.  This allowed the business to securely configure and adapt their business with little IT involvement.  The solution was easy to develop (massive parallel development of independent pages), maintain, secure, and support.  

The tools developed were somewhat coarse-grained (at a page level), but tool building is easily extendable to more sophisticated  UI object integration. ATLaaS describes an generalized way to achieve  this.

The standardization of the internal tool was based on a tablet metaphor.  The pages in the tablets needed certain parameters to work.  All page signatures are satisfied by receiving these parameters from the tabset context area.

The context area can be thought of as the banner for the tablet.  It contains the details of the context (name of who is being worked on, the workitem information, maybe the address, ...).  The context area is responsible for reconciling all signature needs for the pages. The context area initially  supported  search to gather the  needed context. Later it was  improved to accept context passed as a workitem.  

(Note: one long term goal was to make workitem dependent the standard.  This eliminates risk of improper search.  If everything is workitem dependent, the risk surface of any  intrusion is vastly reduced. All security issues are a violation of context.  They  do  not have a legitimate business reason.)

If the  context area can't satisfy the request, the UX design tool will enforce a step up  authorization (to acquire additional  parameters) or the context  area can work with an additional service to gather the required context.  

Optimization of pages allowed us to  build  the  BABE (Business Activity Builder Extension) that empowered the  business  to  build their  own tools.  BABE was not intended for  the business, but was  a tool built  for  IT to  rapidly  support  the  business.  Once the business saw the tool, they  eagerly took ownership.  

The metrics of improvement were significant.

Development

• Page development was improved by 80%

• High percentage of reuse cut testing time by 60%

Training

• Common UI and navigation patterns cut training time by 70%

• Call center reps could successfully handle calls that used to take 2 years of training in just 2 months (highly important in such a high turnover position) (tools designed for the  problem)

Empowerment

• Business could create new tools and have them in production  in 1 day

• Business could add “completion criteria” to a tool to validate that the user completed certain subtasks before completion (every  page and every action  registered for configuration) (standards  enforced)

Security

• Reduced security calls by 80%

• Not platform or application security.  External policies enforced all accesses.  For internal customers on 6 policies - 5 allowing everyone access (if we had a better naming convention this could have been avoided), and the basic policy - is  the user in the right role to access this tool (and does he have business need - workitem)?

• Simplified audit trail because every access has a user/tool/page/action/account context

• Framework created audit trail outside programmer control

• Enforced a business reason for every access. (back to  pet peeve.  Is data classification needed if you  enforce appropriate use on every access?)

Support and Operations

• Help desk calls reduced by  40%

• Simplified page development allowed entry level developers an easy  on ramp (Note: we did lose quite a few very good developers who thought we were turning them into monkeys.  Just imagine AI used in this paradigm).

• Audit trail fed immediate data into system monitoring.  The system reported on every  access of  every system in near real time.  Went down to user level on the web (knew where they dropped out, how long at each  page, etc,). Internal accesses were followed at a tool level (not employee).

• Performance data told the real user journey because it tracked the context of accesses. This data was used to refine tools.

• 95% of future projects followed this guideline reducing design and development time.