Technological Generations: bifurcation or fusion

Random thoughts today as I drove in to work.  As we approach 2020 I sense we’re on another technological transition.

The 60’s brought into being the 360 Architecture and the start of “Big” iron.  This was a major change from how calculating was done, mostly using mechanical devices like card sorters and tabulation machines.  From then on calculations could be written, stored and executed repeatedly.  In the 70’s and 80’s the microprocessor and personal computer came into being.  Another transition occurred.  Computing verses calculation became available to the masses in the Western world.  The vision of having a PC on every desk didn’t seem so far fetched.  Move a little forward a decade and networking became the next transition.  Individual computers where connected in clusters making partitioning computing tasks into specialized roles possible (e.g., Client Server, DBMS, etc.).  A little more forward in time and networking capability and the Internet came into popular usage.  Again a transition; people started using Browsers which placed most of the computing power back in a central server or server farm. Now enter the smartphone, “apps” which enhance the Browser paradigm as well as provide some local computing and storage are changing how people not only process information but interact with each other.  The fusion of telecommunications with computing has created another transition.  This was brought about by another hardware architecture change such as ARM.  But no sooner has ARM become the current and growing thing, others are looking at how software is evolving as the next transition.  Virtual Machines are nothing new.  In fact many people today use them without knowing such, Office applications people are using are virtualized.  This suggests that hardware is becoming an invisible layer, able to be changed out on demand will little impact to the basic operation of a business.

With that I see yet another interesting trend emerging.  Today its impossible to go into any company without hearing the words “Business Model”.  Even my wife has brought up the term more than once.  However, today’s business models representations just drawings, visualizations of concepts.  Much the same as drawings and diagrams in the engineering fields were the same.  It took several generations of “digitization” before engineering models could be used as simulations of the real object in digital space.  Now I see the same evolution going forward with business models.  When I visualized businesses having a digital nervous system years ago I only approach the decomposition needed to anthropomorphize an enterprise: Components such workflow had not yet entered the vernacular of business other than in a shop floor instance.  Soon businesses will be able to design a business model, test it and execute it similar to an engineer designing a physical product, having tools to design and document, test for operational performance and flaws, then build and execution like a vehicle factory I had based my vision years ago on.

 

IT Planning and Agile

Some of the new organizations I’m dealing with are going crazy with “Agile”.  The Hype Cycle  is in full force.  Soon Agile with be advertised to put the kids to bed on time, solve world peace, and feed the world.  The problem I see is not with Agile its with its close cousin “Addle” which is often what I see organizations implementing (I.e., the worst of each methodology glued together).   I will point out that I am neither a zealot for Waterfall or Agile; its a tool and like other power tools –notice the woodworking reference– it should be used carefully.  Too often I’ve seen Agile be used for an excuse for poor or no planning and/or poor development practices.

If one reads the original materials, nowhere does it say don’t plan.  Actually it indicates you need plans, just not at the level of precision and scope previously and wrongly drummed into people’s heads.  Agile suggests or recommends planning in short enough horizons such that the problem doesn’t change before you finishes planning (accuracy) and to a granularity (precision) that is enough to get the job done.  Another way to look at it:

If my problem was to cross the river and you spent five years planning to build a bridge, by the time you actually built the bridge I may have cross the river with a boat and now I’m faced with climbing a mountain (problem has changed).  If I want something to sit on I may want a chair, but it may not need to be designed and constructed to 1 millionth of an inch tolerance –which would cost a significant amount.  I could probably get by with 1/32 of an inch, produced at lower cost but yielding the same level of performance I desire.  So in the end Agile is a balancing act that I believe still requires planning; just different types of planning and a whole lot of thinking.

 

IT Planning Methdology

Started putting together a tutorial deck this morning for an Enterprise Architecture Methodology which is more business based than IT.  Having watched IT over the years get lost in the technology details I though it was about time to create an approach towards really designing Enterprises; the thoughts I had years ago when I presented at the IBM Application Institute and AIAA Operations conferences.  Why couldn’t you design an Enterprise (not just the IT) the way you design any other product.  Years later, several “internships :-)” in other roles within the corporations, and researching various methods from multiple disciplines I’ve started to integrate these into a design methodology:

IT Planning

The above approach has business model as the root where other aspects are details to that end.  That is IT Planning is based upon enablement of the business model, Market Planning, etc. all come from that common root.

Business Models and Organinzational Development

During my mentoring session this morning one of my colleagues posed an interesting dilemma.  The famous success trap.  She was asked to lead development of a solution rapidly.  Which she did famously, so much so that the offering made the IT press channels by word of mouth rather than a publicity campaign.  The problem though is now the company she is working for wants to scale selling it.  The problem however is that the company or rather the various stakeholders in the company don’t understand that the offering is not a simple shrink-wrap product, it is a mixture of product and service and requires customization via configuration setting tuned to the way each organization works and their respective infrastructures.  Thus a marketing person can’t sell a license, have the customer download, install and be successful.  However, marketing just wants a 10 minute dog and pony show from the development organization so they can spread it through the channels to sell just like previous products.

The problem is she needs to either find a service organization that can develop the deep knowledge and readiness collateral to support such or develop such, however, the organization she works in has not come to grips with the concept od services yet.  The way this skunkworks project was successful creates a problem for the organization that understands silos and hierarchy.  It was tough enough to incorporate agile but dynamic groups in addition is a tough pill to swallow.  As I continue my R&D on Enterprise Architecture methodology, I’m thinking there maybe a change formula that will help senior management more accurately understand the challenges of change.  Something like:

 

Change Challenge = { [Organizational Structure Change] x [Process Change] x [Business Model Change] x [Technology Change]} / [Adoption Period]

 

Or a vector model that shows the multiple change dimensions above yields a significant change (e.g., moving 4″ vertical and 4″ horizontal in actual distance is more than 4″.Over 5 1/2 inches which may be too far for the organization to reach in a short period of time).

IT Planning Issues

Several of the problems I’ve been noticing with all the Portfolio and IT Planning methodologies are the build-in assumptions in the process:

Most often in I see planning committees act if the transformations are developed and implemented as simple greenfield or state changes; current state “a” then state “b”.  In most situations this is never the case.  Typically one is forced to address changing the tire while the wheels are turning.  On a small scale initiative such as a software upgrade this is possible but still problematic, witness all the planning for deployments vendors do from readiness to rollback planning.  Businesses are much more complex so when a mission critical component used continuously goes down all hell breaks loose (e.g., Airline Reservation Systems).

The second common problem I see is non-integrated planning or planning in islands.  You would think after years of hierarchical management experience this would have been addressed by implementing a system like Hoshin Planning to provide linkage across the hierarchy but these tools are not so prevalent or understood…maybe because IT behaves as a product development and run organization rather than a service (despite all the recent hype).  I still see efforts to increase programmer productivity outweigh efforts to manage services ongoing.  Not looking at the interdependencies of that various elements in the system is like expecting a sports team to operate effectively in competition without a game plan, one that address every member of the team and its opposition.

This week I’ve stated to map out the IT Portfolio Methodology or rather IT Planning Process to account for such issues as well as the bigger issue alignment to the business.  Originally I figured the spreadsheet I was building to integrate all the components would be enough.  Now I see a complete methodology will be needed.

 

Joy at work

Spent most of yesterday focused on creating a draft of a slide deck.  Previously I would hurry through creating a deck.  However, now I’m having to slow down…because I will not be the one presenting to the executive committees.  So I will not be there to answer questions or bridge the gap in logic.

Over the decades I’ve loved to give presentations on the fly (Chalk Talks) as they seemed more dynamic, interactive and honest.  You’d get to address the areas of topics your audience had rather than a predefined path and conclusion.  It was more exploring the area together.  At SharePoint Saturdays –though I had a slide deck that covered the topic, I won’t follow a script– I’d typically have more “Actor’s Studio” dialogs with the audience as one reviewer put it.  I prefer dialog to speeches I guess.  However, in my role now, I have to ensure my team gets the message across accurately to Executive Management.  So spending time crafting the story and message is more important as the windows of time is so short.  It goes back to a comment I made on Facebook to a friend.  The joy in a job or role derives from developing the precision in executing it more so than the financial remuneration.

Business Theory

Spent morning looking at Theoretical Physics videos (String Theory, M-Theory, and the like).  I know some of my co-workers will question the value of such and ask how do these relate to “real work”.  However, its that cross domain thinking that brought ideas like OOP, Active Directory, etc. into the IT realm.  With all the business architecture and business theories floating around I’m still looking at how I piece these together into a coherent system that allows for another seeming paradox [logical design that includes emotional factors].  I often see the dilemma that business researchers face: an calculus of design that should work, only to be destroyed by human factors.  Consider products that should have been successful earlier: computer watch –which is now all the buzz; PDA which morphed into the Smartphone; etc.  Technically the predecessors to these should have been successful, but something just didn’t click.  One can point out a lack of a single factor and say without this feature … however, how does one explain the Edsel which was an advance to then current industry products.  There is something emotional -which marketers, social network researchers and now Data Scientists are trying to understand.

I had a discussion with a collogue last week regarding patterns –data science, machine learning, etc.– while pattern matching is useful, its results are not always correct as “we” the observer overlay patterns on what we observe.  These patterns we detect maybe just that a coincidence, not a intentional or guided structure.  In other words: “correlation is not causality”.

 

-anyway just insights for me to muse over during this morning’s coffee.  How I apply such to the Enterprise Architecture Methodology I’m writing about is still a TBD.

Follow

Get every new post delivered to your Inbox.

Join 457 other followers