As specialty practitioners continue to focus on specific operational methodologies and tools and argue about which are “best”, the fundamentals are that managing a business is about building, maintaining and enhancing competitive advantage.
Any organization that is not able to build/maintain competitive advantage will fade. And, any organization that is unable to enhance its competitive advantage runs the risk of being leapfrogged by disruptive technologies (e.g. fuel cell powered automobiles that can act as portable electrical generators during power outages).
It all starts with strategy formulation.
We all know strategy is typically developed in isolation and then “communicated” to operational units who are left to interpret the strategy. It’s very easy to identify organizations that have a good strategy with poor operational performance and there are many examples of organizations that are super-efficient at building products customers do not want.
The notion that “everything is a process” at the operational level is not sustainable in organizations where most of the staff members are knowledge workers. There are few end-to-end processes with convenient end point objectives in these organizations. Instead, we find “process fragments” that people, machines and software thread together at run time.
The range of operational methodologies/tools is such that no amount of buying “best in class” rankings will deter enterprising organizations from finding more innovative/cost effective “solutions” to their problems.
Buyers can “save time and spend” or “spend time and save”.
It’s a bad idea, actually, to wait for problems to be identified and to then only start looking for “solutions”.
Some capabilities need to be classified as “strategic corporate assets”, IT infrastructure being a prime example.
Picking an IT Infrastructure – one of the most important corporate decisions you will make.
If an organization subscribes to the notion that the objective of any business is to remain in business, it is important to pick an Information infrastructure that has the potential to address unanticipated future needs, problems and opportunities.
Easily said, not so easy to do.
But, failure to adopt technology that is “future-proof” results in a need to return to the marketplace for new technology in 2-3 years long before the ROI for the old technology has had time to run its course.
Noone understands this better than video production companies, who, having recently gone to HD, are currently tripping over each other to upgrade to 4K.
Meanwhile, manufacturers are getting ready to roll out 8K cameras but, wait, Canon just announced a new sensor that is 60 times sharper than 1080p HD
If an organization wants to be successful, it needs methodologies and tools that are capable of allowing the organization to close the gap between strategy and operations.
If you are a subscriber to my collection of rants, you will have seen comments on the different information architectural needs of transaction processing applications versus applications/environments needed to carry out strategic planning.
Transaction processing applications pull/push messages from/to engines that provide very specific services. A Case-based run-time environment that showcases seamless interoperability has the wherewithal to provide decision support, collect operational level data, share data and build up a history of transactions, Case by Case. All you need in such an environment is the ability to establish a cursor position in an RDBMS and engage processing.
Knowlegebase applications require a different IT architecture.
Here, we have a need for graphic display of thousands (sometimes tens of thousands) of records, organized in multi-root hierarchical trees, with free-form search capabilities across all records. The records typically come from multiple Entities where, in some organizations, there is no duplication of data elements across Entities (i.e. resources, customers, products, competitors, policy/procedure/legislation)
The focus can be on a particular structured data element value, text, key words, even images, and the scope of any search is likely to extend to current and historical data as opposed to current data only.
The 2nd difference between Kbase application IT architectures and the usual structures found in traditional RDBMS applications is that in a Kbase you need to be able to put a simultaneous focus on all records, not just the “hits”.
Users are likely, some of the time at least, to be more interested in what a search did NOT find as what was found. (i.e. McDonalds today wants to put an outlet at a location where Wendys is, tomorrow they may want to put an outlet where Wendys is not).
The 3rd and final difference is that the “structure” of data in a Kbase is likely to change on-the-fly. (i.e. I have records organized by City – following a search I may want to cluster some of these temporarily or permanently by type of business, keeping the City structure intact).
It’s easy to understand that in a Kbase application you need to load record stubs for all records into memory, carry out searches and then build your KMap out of memory.
Different User mindset, different User Interface, different architecture.
See “It’s Time For You To Get Your Big Data Organized”
Stay tuned for more information on “Cases of Cases” in a subsequent blog post.