The Innovation Dilemma

Innovation is perhaps today’s ultimate buzzword and most over-hyped topic. People can’t seem to get enough of articles and dialog on how Innovation is the answer to any number of potential issues – yet in all the countless discussions occurring online and in print about this topic, how well do any of the folks discussing innovation really understand it? That’s part one of the dilemma. Part two of the dilemma is that for all the lip service about how Innovation needs to be fostered, are we actually in fact fostering it in any meaningful ways (or perhaps worse yet, might we in fact be hindering it through current trends)? We will examine both parts of this question in today’s post.

Let’s start by helping to define what Innovation actually represents in a meaningful context. We’ll begin this by explaining first what innovation is not; it is not:

• A marketing slogan
• A collection of admirable ideas awaiting exploitation
• The province of rarefied genius or Silicon Valley risk takers
• Accidental or otherwise random in nature 
• And lastly – Innovation is not thought (e.g. Innovative Thinking) – thought without application perhaps qualifies as day-dreaming. Innovation is Actionable Thought embedded within the context of a larger problem solving activity. 

Innovation is a process, not an individual event. That process has a ‘macro’ or Global perspective as well as a Local perspective. In other words, the Global process of Innovation encompasses all of the Local processes – the smaller efforts impact the cumulative achievements at the Global level. There is also often synergistic inter-relationships between various local innovation “threads.”

An example of a complex Innovation process

Definitions (Innovation in Theory):
Innovation – This represents the deliberate (reproducible, consistent) process associated with solving specific problems. The process is evolutionary, incremental and focused on specific, well-defined goals. The key concept here is that Innovation is not an anomalous or ephemeral activity; it is most definitely not “magic happens here.”

Local Innovation – Any individual application of an innovation process within a closed community/entity.  This does not imply that the community or entity is somehow cut off from the global community, merely that it has its own a unique charter.

Global Innovation – Any number of local communities may be working to solve the same problems. These problems can be referred to as innovation threads. The level of collaboration or cooperation will vary between these communities, yet on the whole there is usually some information exchange that at times will allow individual local innovation to influence or otherwise contribute to global innovation progress (and conversely, progress acknowledged at the Global will of course any number of Local efforts).

Innovation Threads – An Innovation thread is the collective effort towards resolving a unique problem. Obviously, there are cases where one group defines a similar problem somewhat differently, but in general the progress made in one variation of a particular thread may be applicable to another similar one.

Innovation in Practice

One of the best examples of what differentiates innovation in popular mythology with Innovation in practice is the case of the Wright Brothers. Their story is not one of a handful of good ideas punctuated by the glorious realization of their dreams of flight, but rather the many years of tireless work and massive amount of invention that had to occur in order to achieve a specific goal associated with one very famous problem – “how to achieve powered flight.”

The Wright B Flyer

The Wright Brothers didn’t just look at a bird and shout “Eureka.” They redefined the science of aerodynamics, testing hundreds of airfoil designs. To do this they had to redefine the mathematics of aerodynamics, they had to invent the wind tunnel and more. In short, they had to solve 100’s of related problems in order to resolve the main problem that started their quest. Theirs was an example of local innovation – however it was so profound that it completely redefined the Global scope of innovation for aerodynamics. And we still fly in planes based entirely their designs and principles today.

Another important characteristic of what the Wright Brothers did was its entirely practical focus. Everything they did was goal-focused. This differentiates it from many research and development programs that have arisen over the past 50 to 75 tears in that oftentimes research programs do not have specific, tangible goals in mind. (in other words, they are not entirely pragmatic in nature).

Dilemma 2
Now that we might have a better idea of what Innovation actually represents, let’s consider whether we as a society are actually encouraging or discouraging it. To do that we need to consider a couple of related questions, including:

1. Can innovation be taught, and if so how would that happen?
2. What sort of incentives might help to spur innovation?
3. What might represent disincentives for innovation?

We will answer these questions one at a time…

Can Innovation be Taught?
Yes, it can (and we will explore that topic in more detail in a future post). But is our current expectation of what represents education that fosters innovation accurate – well, no. In our previous example of practical innovation (The Wright Brothers), the main idea was that the entire exercise was problem focused. What they learned, invented and achieved was all focused on a central goal. The vast majority of education today is in contrast not goal-focused. Moreover, it tends to be highly standardized and this trend is getting worse every year. There are some exceptions of course, but for the main part our educational systems today judge students based upon conformity of thought as evidenced through an ever-expanding list of assessment tests. This shift towards assessment testing has a chilling over-all effect on curriculum, making it more and more abstract and less focused on systematic problem-solving. In the United States, we are now teaching almost entirely to the test.

The way most experts have framed education that might somehow foster innovation is by decrying that more education ought to include science and math education (STEM). So, remarkably all of the focus towards achieving more innovation has been directed at what is being taught as opposed to how it is being taught. There is an obvious flaw in this logic that is borne out in almost every field of practical application. This is a massive and complex topic and we are of course just skimming the surface.

What sort of Incentives might encourage Innovation?
Well, this might include incentives both within education and in industry. Incentives within Education might include rewarding problem-solving skills in terms of assessment or college admission and structuring curriculum to encourage development of problem solving skills. These types of skills are in some ways diametrically opposed to the type of assessment testing which is currently so popular now. The idea is of course, is being able to question rather than mimic current thinking in order to develop the types of new perspectives needed to progress beyond current capabilities.

In industry, many assessments are more or less natural – in other words – solutions that effectively solve problems become popular and profitable. However, many such solutions can’t get funding to reach this point – so one area that can be improved is the access to capital (both in the government and private sectors, and for the federal sector R & D can become entirely problem focused rather than random).

What things tend to discourage Innovation?

A misdirected educational system, as discussed already, represents a serious discouragement towards fostering education, but it is not the only problem. Other issues include:

• A misguided dilution of labor incentives. This sounds a little complex but what it means is that since about the year 2000, a two-tier technology labor scenario has arisen in the United States. The introduction of temporary Visas based upon the mistaken notion that there was a technology labor shortage has in fact displaced several million technology workers here and resulted in the introduction of millions of IT workers who get paid roughly half of what the standard wage would otherwise be. Add this to off-shoring, and what we have created an environment of uncertainty in area where we should be fostering confidence in terms of securing a large, stable technology workforce. 

• Within individual organizations, despite the hype that seems to imply otherwise, risk-taking and divergent solution approaches are most often discouraged. For organizations to become innovative there generally needs to be some cultural transformation – this is very difficult to achieve. 

The goal with this post was to help refine the dialog about innovation a bit – get beyond the platitudes and start discussing how it can or should work. We will revisit this topic again in coming months…

Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas
#TechnovationTalks

Read More

Building Effective IT Strategy - part 3

In our last two post on IT Strategy, we highlighted how Strategy can be structured, how it differs fro Tactics (although we will explore that in more depth in this post) and how to employ a consistent process towards developing strategy. The first two steps involved determining what the core strategic approach might be; the second focused on goal-setting. The third and most difficult part is assigning actions to goals...

So, using our Big Data case study, how would begin to translate the higher level goals into definitive actions and then what types of tactics might be used to carry out those actions?

This illustration highlights where Big Data fits within a larger set of Strategic elements in an overall Transformation initiative. This type of representation helps to define relationships, dependencies and quantifies where work needs to happen once the higher level goal-setting has been defined.  

The types of actions that might be involved with actualizing a Big Data Strategy might include the following:

• Creation of a team or center of excellence to manage the technology / project
• Definition and Deployment of a proof of concept 
• Acquisition of the raw data intended for use in the Big Data solution (so let's say this is for an energy company it might include SmartGrid sensor information).
• Acquisition and / or development of the Big Data Platform

All of these possible actions of course imply a number of key decisions that must be made; the following are a few examples of those;

• Determination of Big Data technology to use (triple store, key value etc.)
• Determination / selection of a Big Data solution hardware platform
• Determination of modeling or data profiling approach
• Choice of BI platform for data visualization

All of this information is going to be necessary in order to complete detailed roadmaps and ensure accurate estimates for those who manage the IT portfolio process in any given organization. Actions can then begin to be translated into milestones with traceable costs. Those Action-Milestones are then mapped specifically to goals/objectives previously identified in the higher level strategy.

Now, how does action to goal alignment involve Tactics? In the case we've introduced and in most others, the tactics involve the core tools for decision-making. So, for all of the decisions listed above, individual analyses of alternatives might be conducted. For product decisions, run-offs / competitions / evaluations and source selection processes are applied. For design considerations, an architecture approach is applied. All of these activities can also fit within a lifecycle process - all of this represents Tactics.  Why? because, we could use roughly the same lifecycle approaches for any type of technology - whether it is UAV development, Quantum Computing or building a SharePoint portal. It is the interchangeable actualization toolset for all strategy.

The hardest part of aligning Strategy, sub-strategies and tactics is when you find yourself in a very large transformation effort (one perhaps dealing with 100's of systems, dozens of technologies and perhaps thousands of people). There is no single solution, tool or approach for managing that - it represents what mathematicians often refer to as a unsolvable problem (NP Hard). We will look at IT Transformation and intense complexity in an upcoming post.


Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas
#TechnovationTalks

Read More

Building Effective IT Strategy - part 2

In yesterday's post, I introduced three elementary categories for IT Strategy:

1. Product 
2. Portfolio
3. Transformation

I then pointed out that each of these follows a basic cycle of:

1. Determination of Strategic Approach
2. Goal-Setting
3. Assigning actions to goals

So, now as promised, I will use this to take a look at a specific scenario. But before we begin, let me mention an important caveat to the three categories listed above. While all strategy tends to fit within these, not all strategy has to exist at the highest level. In other words, there are various levels of Strategy that are still abstract enough to remain differentiated from Tactics.

In this case study example, we are going to look at Big Data. Big Data is something that many organizations might consider important enough and large enough to develop a strategy around. However, just looking at the moniker "Big Data" and one might instantly wonder - well, doesn't that belong as part of a larger "Data Strategy." Yes. And then wouldn't that also imply that the Data Strategy would be part of a larger Strategy. Again the answer is yes - and in this case the whole thing lines up neatly like this:

• Portfolio Strategy
•  Data Strategy
• Big Data Strategy

So, this begs the questions, just how we might first differentiate the lower level strategy from higher level strategy and then perhaps even more importantly, how do you ensure they stay in alignment?

Differentiation:
This tends to be managed something like this - you begin at the top level with the superstructure of where everything is supposed to fit as well as common capability / design principles and objectives. Then as you move down the Strategy levels, things progress from conceptual expectations to logical descriptions. The top level is the most open or flexible; the bottom level the closest to expectations regarding solution execution.

Reconciliation:
Side by side with the differentiation activity is integrated road-mapping - each level below fitting neatly into the one above. The other big component here is alignment of Strategy with Architecture which provides the other key reconciliation tool (if used properly).

So, how would a Big Data Strategy fit into an Enterprise Data Strategy? First, it obviously in most cases extends something that already exists. This then implies either replacement of existing capability or addition of new ones. Now let's jump back to the process we mentioned earlier - Step 1 - assigning portfolio strategy is complete. How would we attack goal-setting for Big Data?

This by the way, is where perhaps more than half of the organizations trying to adopt Big Data solutions are getting tripped up right now. A poor example of goal-setting would be - "let's do a POC without a clear path of how to exploit this technology yet" (mainly because everyone else seems to be doing it. A better approach might be:

1. Define the set of possible Use Cases associated with your organization (where Big Data might make an impact)
2. Choose one or two that can be effectively demonstrated and measured - let's say one might be the rapid development of a user driven BI solution based on unstructured (web/social media) data. 
3. Develop a clear path as to how; a) the initial capability could be rolled into the larger existing ecosystem to avoid silos or solution-fracking and b) add new functionality to the emerging Big Data solution - consistent with overarching organizational goals. 

Step 3 is assigning actions to goals. We'll take a look at that in our next post...

Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas
#TechnovationTalks

Read More

Building Effective IT Strategy - part 1

Every great endeavor begins with a strategy, well that may be true but was it an idea, a single spoken command, a drawing on a napkin? How do we quantify precisely what Strategy represents?

In military history, Strategy is the highest level of planning - the combination of complex goal-setting and the definition of an over-arching approach designed to achieve said goals. In the American Civil War, A. Lincoln decided early on that the North must cut the Confederacy in two by taking the Mississippi river and to stifle commerce using a massive naval blockade. This strategy was even given a name - the Anaconda Plan. The rest of what happened in the war was mainly tactical in nature - so in the case of the military analogy, Tactics are the detailed actions necessary to fulfill elements of the larger Strategy.

The interesting aspect associated with Tactics is that they tend to be "reusable components." In other words, you develop tactics that can be used regardless of the Strategy of that may employ them. This metaphor translates well from the military analogy over into real-world IT.

Lucky for us, the world of IT isn't much like war except in the sense that there is quite a lot of chaos and a need for planning to manage complex situations. Let's try then to define IT Strategy...

IT Strategy is the ongoing effort to guide organizational exploitation of technology over a multi-year period. It is ongoing because in IT (which is hopefully not the case for war) there is no definitive end-state goal. In other the words, the end state is always moving to right, reflecting the evolution that has already occurred as well as the oncoming waves of newer disruptive technologies.

That's the high level view, but IT has its own unique spin on Strategy which makes it possibly more divergent from the war analogy. In IT there are several distinct types of Strategy; these include:

1. Product Strategy - Focused (perhaps analogous to a Theater strategy in war)
2. Portfolio Strategy (otherwise referred to as Capability Strategy) - Comprehensive
3. Integration / Transformation Strategy - This is not just focused on solution integration - it is the larger question of how to redefine and reconcile an entire portfolio 

Depending on the organization in question, they might require only one or perhaps all of these types of strategy at any given time. A software company (one that is solely focused on one software product let's say) would definitely want to use the first type of Strategy to help define their product roadmap, but might not need the other two. 

So, step 1 is determining what type of Strategy is required. Step 2, regardless of the strategy category is a goal-setting exercise. Step 3 is assigning goals to action. In our next post, we will use a Case Study to look at Steps 2 and 3 in more detail.

Policy in the context of IT Strategy generally represents tactical guidance given on an organizational level - this tends to fall under either Portfolio or Transformation Strategy (or both)


Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas
#TechnovationTalks

Read More

What is Digital Transformation?

It sounds a bit misleading perhaps - maybe one gets the impression that this is something akin to rendering special effects for movies. In mainstream IT however, Digital Transformation has come to mean something quite different.

The shorthand definition for it is this; "the coordinated integration of all customer-facing digital capabilities." This includes mobile, web and social media. There is perhaps an implied level of underlying integration supporting of all it, but that isn't always required - at least not at first anyway.

We use the word "customer" here a bit loosely, as Customer can refer to any users or members of a certain organization. So, a government entity might consider citizens as customers and the military could consider its rank and file 'customers' in this sense also. Digital Transformation can occur in just about any type of organization specifically because the set of technologies involved is common across industries.

Ten years ago a 'Digital Transformation' would have likely been referred to as a "Portal Strategy." At the time, it was thought that the portal metaphor (and associated software products) would suffice to meet all customer-facing needs. A typical portal might include the following elements in 2005:

• Extranet
• Intranet
• Collaboration tools
• Content Management tools

What happened since then? Well, at least two and possibly three revolutions in technologies with more on the cusp; the key revolutions include:

• Mobile - (not laptops of course, but the smartphone and mobile)
• Social Media - some re-branding of collaborative capabilities merged onto smartphones as well
• Cloud Computing - re-branding of visualization - and importantly opening that up to customer facing apps (web and mobile).
• with Big Data coming on strong (although to be honest, most places still don't know how to use it so it's an outlyer with respect to customer facing technology).

On the backend of course are all the systems that actually make the organization go - but for the customer this is like the engine within the chassis. Most customers don't care what's under the hood until or unless it fails to perform.

Digital Transformation is a lot like enterprise integration but on the customer facing side of things. It is the alignment, coordination and update in tandem of the core mission apps and interfaces. And it can potentially include the Web of Things as well. So for example, if you have a grocery store then perhaps there are kiosks inside and gas pumps outside and nifty new cooler video displays etc. All of that technology is customer-facing so for a true transformation it all must be managed within a shared context.  The transformation has one goal - to go from a heterogeneous mix of random technologies to a holistic solution designed to facilitate strategic goals.

So, how does an organization undergo a Digital Transformation? We will look at this in more detail in one of our upcoming posts.

Some organizations (like larger retailers) face dual Digital Transformations; in so much as they must serve both traditional customers and the needs of many thousands of employees (with separate capabilities) such as in the example above targeted to employees...


Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas
#TechnovationTalks

Read More

The 5 Rules of IT Architecture

It is perplexing that after nearly 20 years since the emergence of IT Architecture as a discipline, there is still so much confusion surrounding what architects do (or more precisely, what they are supposed to do).

Many people in IT refer to themselves as "Architects" now - yet how can employers or colleagues quantify or otherwise validate that they are indeed actually Architects? I will propose five simple rules or tests to help clarify this:

Rule 1 - Architects architect, just as writers write. Architecture is by definition a design process. Any architect who doesn't or can't produce design is not functioning in the assigned role. An important corollary to this is that you cannot be an effective Architect and focus only on one 1 thing in IT - for example 1 tool / product. Architecture is a discipline, not SME knowledge in one particular area. The reason why this is the case is that most of the time focus on one product leads to a very myopic view of how to solve a problem (every issue begins to look like a nail for your one hammer).

Rule 2 - Architects follow a design process; whether it is geared towards EA frameworks or application design is somewhat irrelevant. What is crucial is that an approach is followed. Not having an approach means not having standard design expectations or deliverables. A lack of design diligence is analogous to a brick and mortar architect using cocktail napkins instead of blueprints to design skyscrapers.

Rule 3 - Architects are honest brokers, not blind followers. Why is this important? Well, it matters because the design process is where most key IT decisions get made. The Architect must take a certain level of responsibility for the outcomes associated with their work - just as brick and mortar architects do. If a client building a Summer house on the beach demands that the structure be built atop sand without concrete or wooden supports, the Architect must let them know the house will likely suffer a structural failure shortly after completion (if not before).

Rule 4 - Architects are problem solvers. Anyone working as an architect who deliberately avoids facing and resolving the tough issues is unlikely to achieve any sort of measurable project success.

Rule 5 - Architects must be able to communicate with the organization they are serving. This applies both to having personal effective communication skills, but also to the projects themselves. Projects that aren't transparent or collaborative tend to take longer and experience high failure rates.

IT Architects tend to be placed in high-profile, high-pressure roles. We who serve as IT Architects are constantly being judged not only personally but also as a profession. Part of the reason the latter half of the previous statement is true is due to the inconsistencies in outcomes for architecture-related projects.

However, if both Architects and their colleagues used the 5 rules above to define what should be happening, the outcomes for most architecture projects would improve dramatically.

Design requires visualization - effective visualizations can be notation-driven or conceptual (as in the above example) 

Copyright 2014, Stephen Lahanas


#Semantech
#StephenLahanas

Read More