A Framework for Evolutionary Artificial Thought

This past week, I was making the long commute between Dayton and Columbus, Ohio and trying to amuse myself the best I could – in this case by listening to a college course on the fundamentals of Particle Physics. One might not think there is an obvious connection between Particle Physics and Artificial Intelligence, but it turns out there is at least one. The connection, in my mind at least, was the framework used in Physics to help organize the field of subatomic particles – it’s known as the Standard Model of Particle Physics.

In the Physics world in the early 20th century, as in the field of Artificial Intelligence now, there was a tremendous amount of information which was obtained from various sources and very little ability to place it all into a unified context. We discovered particles, defined new mathematics and reinvented philosophy through Relativism and Uncertainty, yet without a guiding framework it all must have seemed terribly chaotic and random for those working in the field. Out of that chaos emerged a framework though; half invented, half discovered – one that helped to focus technology, philosophy and application of the science in question. I thought to myself, this is exactly what we’re missing with Artificial Intelligence. But as I posited in my last post, the framework that’s needed might also require a philosophical adjustment – one that illustrates Intelligence in the context of a combination of evolutionary capabilities which might best be described as Artificial Thought. In that article, I tried to make the philosophical case for something like that might make sense, in this post, I’m going to get a bit more specific and examine the more pragmatic aspects of a Framework for Artificial Thought.  

Let’s start at the beginning – what does this or any such “Framework” buy us? In the case of The Standard Model of Particle Physics, the framework provided the following benefits:

1. The ability to place a number of potentially divergent concepts and discoveries within a unified and coherent context
2. The ability to explain the nature of something in a manner consistent with empirical data
3. The ability to support a variety of predictions, like for example the discovery of specific types of new particles, the most recent and famous of those being the Higgs Boson

For Artificial Thought, the benefits might be a little different, but perhaps not as much as one would think. The high-level value proposition associated with a framework for Artificial Thought might include the following benefits:

1. The ability to align a diverse set of AI theories, techniques and technologies within a coherent, unified context
2. The ability to define a clear evolutionary path within that context whereby component capabilities can be combined to achieve ever greater orders of Thought and eventually Intelligence
3. The ability to better chart and predict success in achieving Thought or AI milestones

I suppose the biggest difference between Particle Physics and Artificial Thought is that we’re bypassing the need to discover the functions of natural intelligence on the biological level. In other words, there are no CERN-like labs available to discover Thought in progress the way we discover subatomic particles. This could make our efforts harder to achieve, but perhaps only if our goal was to recreate natural intelligence as opposed to generating capabilities which are logically similar if not actually organic in nature. This brings us back to the central premise in the previous article, that recreating the most complex and comprehensive capability is a hell of a tough goal and we should instead worry mostly about intermediate steps rather than the end game (and I might add without getting lost in the growing tangle of 100’s of immediate, lower level details or approaches and opportunities)

Let’s take a look at what a Framework for Artificial Thought might look like…

The framework resembles an IT architecture because in a sense that’s what it is. Imagine a situation in a few years where we have a galaxy of AI-related capabilities, how might they work together and to what end? This view gives us a hint as to what that might look like. It does more than that though, it also shows how we move from lower-level Thought to higher-level Thought and it also begins to illustrate the potential for orders of Artificial Intelligence through integration of Thought capabilities (both within and across Tiers). The Tiers themselves mimic to some extent the natural intelligence we’ve referred to (both human and otherwise) by illustrating how basic capabilities might evolve into something more.

Tier 1 is Awareness and I think it’s safe to say this is the area where traditional AI has made the most progress thusfar and that only stands to reason. As we discussed before, Awareness in this context is nothing at all like Self Awareness. We can imagine a rover crawling along the rocky, barren landscape of Mars, avoiding obstacles by becoming aware of them through sensory apparatus and that fits this tier just fine. Is the rover Intelligent? Not really, yet some of the rovers we’ve built or are building can potentially operate on their own without explicit direction or intervention from human operators. This is a good starting place…

Tier 2 might witness our rover becoming more sophisticated, perhaps learning from its environment and building upon its experiences yet still basically reacting to environment. As you might have noticed from the diagram, it’s clear that Artificial Thought will occur both individually and collectively – something perhaps not fully anticipated by the founders of AI back in the 50’s and 60’s. This has critical implications to the applications of Artificial Thought, for example in the case of the rover, the implication might be that it distributes some of its higher function elsewhere. If maintaining higher Thought from Earth presents difficulties due to the 8 minute travel time for instructions, then perhaps there might be cognitive capability in another part of the lander or on an orbiting satellite. The key idea here though is that the rover itself doesn’t need all of the cognitive capability itself, which would become even more important if for some reason the rover was instead some type of Martian UAV and needed to operate for long periods of time with minimal fuel. The bottom line, though, is that Collective Thought is still Thought, regardless of how it might be distributed or otherwise combined. This is one area where our current view of individualistic human-mimicked Thought really diverges from where we’re headed.

The question begins to arise in relation to Tier 2 capability as to whether if we combined all of these functions and integrated them somehow, would we in fact achieve a level of Intelligence? For the sake of argument, let’s say yes, that it would. If we combine all capabilities that fit with Tier 1 and Tier 2 Thought, we might say we have achieved a “level 0” order of intelligence. I don’t think Tier 1 by itself would justify that assignment, yet when we look at what Tier 1 represents it does seem to mimic much of what might be required for a lower order of intelligent life to survive.

With Tier 3, things get more interesting. This is where Watson and some of the other more ambitious AI projects have been focused with limited success, but still some progress has been made. The distinction between reactive and proactive, between simple and complex is a big leap and one that not all Artificial Thought has to make. It’s important to keep in mind here also that the Tiers are not actually separate from one another, rather the higher tiers build from the lower. This model is evolutionary on several levels, both in terms of building capabilities up but also in our ability to mimic the progression of Thought metaphorically from its beginnings to somewhere at least close to how we view it. Beyond those considerations, it also represents a real-time integration architecture as well – with lower information feeding higher level capabilities. If enough integration (across Tier 3 capabilities) occurs then we might say that we’ve reached a “level 1” intelligence.

Of course, I haven’t defined what level 0 or 1 orders of intelligence represent, but the taxonomy might look something like this:

• Level 0 – An order of intelligence mimicking primitive life
• Level 1 – An order of intelligence mimicking intermediate forms of life, but not humans
• Level 2 – An order of intelligence that truly mimics human intelligence
• Level 3 – An order of intelligence beyond human intelligence

Each of these orders or levels of Intelligence involve a multitude of complex Thinking behaviors (I’ve abstracted the view to a great extent for this dialog). The framework I’ve outlined above isn’t focused on level 2 or 3 Intelligence, we can leave that for science fiction for now. But, the next ten years could see some remarkable breakthroughs on the lower levels.  “It thinks, therefore it works,” might be a good corollary to Descartes’ original premise.

Copyright 2016, Stephen Lahanas

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

IT Architecture for the Enterprise

Semantech: IT Architecture in the Enterprise from Stephen Lahanas

Read More

Understanding Data Architecture

Someone asked me what at first sounded like a very straightforward question earlier this week; "what is Data Architecture" - or more precisely, what does it mean to you. Usually, I'm not usually at a loss for words when it comes to expounding upon IT Architecture related topics - but it occurred to me at that moment that my previous understanding of what Data Architecture really represents is or has been a little flawed or perhaps just outdated. So I gave a somewhat convoluted and circumspect answer.

Where does Architecture fit within this picture?

The nature of what's occurring in the Data domain within IT is itself changing - very quickly and somewhat radically. The rise of Big Data and proliferation of User Driven discovery tools represents quite a departure from the previous more deterministic view of how data ought to be organized, processed and harvested. So how does all of this effect Data Architecture as a practice within IT (or more specifically within IT Architecture)?

But before we dive into the implications of the current revolution and its subsequent democratizing of data, we need to step back and look again the more traditional definitions as to what Data Architecture represents. I'll start with a high level summary view:

Traditional Data Architecture can be divided into two main focus areas; 1 - the structure of the data itself and 2 - the systems view of whatever components are utilized to exploit the data contained within the systems. Data in itself is the semantic representation or shorthand of the processes, functions or activities that an organization is involved with. Data has traditionally been subdivided (at least for the past several decades) into two categories; transactional and knowledge-based or analytic (OLTP vs. OLAP). 

Now we'll move to a traditional summary definition of Data Architecture practice:

Data Architecture is the practice of managing both the design of data as well as of the systems which house or exploit that data. As such, this practice area revolves around management of data models and architecture models. Unfortunately, the application of Governance within this practice is sporadic and when it does occur is often split into two views: governance of the data (models) and governance of systems (patterns and configurations). 

So, that seems to be fairly comprehensive; but is it? Where does Business Intelligence fit in - is it part of the data management or system management - is it purely knowledge focused or does it also include transactional data? For that matter, do Data Warehouses only concern themselves with analytic data or can they be used to pass through transactional data to other consumers? And isn't Big Data both transactional and analytic in nature? And BTW- how do you model Big Data solutions either from a systems or data modeling standpoint? Now - we start to begin seeing how things can get confusing.

We also need to take into consideration that there has been an attempt made to standardize some of this from an industry perspective - it's referred to as the Data Management Book of Practice or DMBOK. I think in some ways it's been successful in attempting to lay out an industry taxonomy (much like ITIL did) but not as successful in linking that back into the practice of Data Architecture. The following diagram represents an attempt to map the two together...

There isn't a one to mapping between DMBOK and data architecture practice, but it's close

One of the areas that the DMBOK has fallen short is Big Data; my guess is that they will need to rethink their framework once again relatively soon to accommodate what's happening in the real world. In the diagram above, we have a somewhat idealized view in that we've targeted a unified governance approach for both data modeling and data systems.

Let's take a moment and discuss the challenges presented by the advent of new Big Data and BI technology. We'll start with BI - let's say your organization is using Oracle's BI suite - Oracle Business Intelligence Enterprise Edition (OBIEE). Within OBIEE you have a more or less semantic / metadata management tool called Common Enterprise Information Model (CEIM). It produces a file (or files) that maps out the business functionality of all the reports or dashboards associated with the solution. Where does that fit from an architecture standpoint? It has a modeling like interface but it isn't a 3rd normal form model or even a dimensional model. It represents a proprietary Oracle approach (both as an interface and modeling approach). It allows you to track dimensions, data hierarchies and data structures - so it is a viable architecture management tool for BI (at least for OBIEE instantiations). But some traditional Data Architecture groups would not view this as something the architects would manage - it might handed off to OBIEE administrators. This situation is not unique to Oracle of course, it applies to IBM / Cognos and other BI tools as well and there's a whole new class of tools that are completely driven by end users (rather than structured in advance from an IT group).

Now let's look at Big Data. Many of the Big Data tools require command line interface management and programming in order to create or change core data structures. There is no standard modeling approach for Big Data as it encompasses at least 5 different major approaches (as different say as 3NF is from Dimensional). How does an architecture group manage this? Right now, in most cases it's not managed as data architecture but more as data systems architecture. The problem here is obvious; just as organizations have finally gained some insight into the data they own or manage - a giant new elephant as entered the room. How is that new capability going to impact the rest of the enterprise - how can it be managed effectively?

Back to the original question - what is Data Architecture. I'd like to suggest that the practice of Data Architecture is more than the sum of its traditional activities. Data Architecture is the practice of understanding, managing and properly exploiting data in the context of problems any given organization has to solve. It is not limited by prior classifications or practice but has a consistent mandate to be able to represent and hopefully govern in some fashion data as an asset (internally or shared collaboratively). Data Architecture as we know is going to change quite a bit in the next two years and that's a very good thing.



Copyright 2013, Stephen Lahanas



#Semantech
#StephenLahanas

Read More

The Value of Architecture Assessments

While many people are becoming somewhat familiar with IT or Enterprise Architecture, relatively few know much about Architecture Assessments. This is unfortunate given the significant value proposition such exercises provide. For example, had one or more Architecture Assessments been provided for Healthcare.gov during the course of the project; it is unlikely that the Obama administration would have been surprised by the current mess it's now facing.

Problem Space analysis is one of the techniques used with assessments - it can apply
both to the business and technical aspects of a project

An Architecture Assessment is also different than other traditional Architecture activities in that the expectation is generally that third-party personnel are more likely to perform them. The reasons for this include the following:

1. Assessments are one of the key tools involved in IT oversight activities (sometimes referred to as Independent Validation and Verification or IV&V).
2. It is more likely that an accurate assessment can be obtained by architects / investigators without a vested interest in the project. 
3. The skillset of the person doing the assessment is critical - it needs to be an architect and not merely a technical or product expert. This is the only way to ensure that all options / alternatives are properly considered / assessed. 

So what exactly is an Architecture Assessment? A typical assessment tends to include the following categories of activity:

• Information Gathering  
• Design & Project Review
• Design & Project Recommendations

An assessment also typically includes one or more types of specific analysis as well:

• Analysis of Alternatives
• Root Cause Analysis
• Problem Space Mapping & Resolution 

One way to capture alternatives is through Decision Trees.

Perhaps the most important function that an Architecture Assessment can provide is a mechanism to challenge assumptions and combat complacency. One of the main reasons that IT projects fail today is because there is generally no incentive or expectation to raise issues or problems. Rather than being viewed as a healthy activity - identification of the problems is feared in itself and thus ensures even more pain later on when the issue finally surfaces (which they always do).

When compared to the cost of the rest of a typical IT project (and any potential loss or cost overruns associated with problems that aren't identified or managed in a timely fashion), a relatively brief assessment exercise is generally less than 1% of total cost yet could make the difference between success or failure...



Copyright 2013, Stephen Lahanas


#Semantech
#ITarchitecture

Read More

Deconstructing Time part 5 - Intuitive Physics

Before we dive into modern Physics theory I think it's probably appropriate to introduce a concept and provide a critique on the current way Physics is practiced. This is not meant to be critical per se - it's simply another way to illustrate the method I described in the first post on Deconstructing Time. Any time an IT Architect such as myself accepts an assignment, we run the risk of setting foot within an entirely new domain - at least it is new for us. Over the years, I have worked in the military, in Healthcare, in manufacturing, in telecommunications and so on. Until now though I had never immersed myself in the field of Physics. Like many folks, I have followed Physics as a news item and studied key concepts as part of my education - but I was never asked to create or validate any solutions for the field.

Intuition isn't as painful as it looks...

The term "Intuitive Physics" then is not meant to represent something wholly unique to that field - it could apply equally to Healthcare and then perhaps be called "Intuitive Medicine." What I'm referring to with this concept is the ability to take a generic (Cross Domain) methodology for problem-solving and direct it at an entirely new field without being or becoming an expert in that field. In fact, not being an expert in the field it is being directed at is one of its major value propositions in that one can avoid Group-think traps that tend to snare many of the more formally accredited members of the group. The reason I use the word "Intuit" is because the ultimate goal of the methodology is the ability to assimilate enough knowledge from the specific field quickly enough to parallel instinctively or intuitively the major lines of logical though that have developed or will develop. Again, this isn't because of any unique skills or abilities per se other than the ability to keep one's mind completely attuned to problem solving instead of getting bogged down in the internal politics and distractions of any given group.

This is a process or experience that has worked more or less the same way for me as an architect for more than 15 years. In every field where I was asked to provide IT solutions I was able to anticipate major issues and parallel the thought processes that went into the current solutions and those that were driving the next generation requirements. If I wasn't able to do this then instead of needing months or weeks to get ramped-up in a new field, it would take me years - Intuitive Solutions design then is a very pragmatic skill for IT practitioners who "jump domains."

The irony here is that intuition lost its place in physics for many decades after the 1930's

Getting back to Physics, while I'm still early in the process of immersion and can't perhaps really consider myself immersed in the sense that I usually achieve on most assignments (as this investigation is entirely virtual in nature and is part time), I have still begun to notice certain characteristics about the field. I always make observations like these while on assignment in order to better understand why something is or isn't working well within a particular environment - this helps drive solution options as well as helping to define constraints, dependencies and risks. So, for Physics thusfar I've noticed the following things:

• In general, there is a lack of community support for questioning core assumptions. This seems to be changing, but appears to have been very rigid for about 75 years. I should point out that this situations changes over time as evolutionary 'bursts of dissent' often drives major advances, but these have historically occurred far apart. The pace of these bursts may be on the verge of some serious acceleration.  

• In Physics, there seems to be some difficulty viewing concepts in holistic perspectives. This is a common phenomena and occurs whenever the subject matter becomes sufficiently complex - which is also why it is very widespread in IT. In Information Technology we refer to this as "Silos." In Physics though the problem seems worse - I've yet to view visualizations that link all of the core concepts of modern physics together within shared contexts. I'm still looking but if I don't find them I will provide a few myself in order to demonstrate what's missing.

• Physics is overly dependent on the proof. Now this may sound counter-intuitive at first but it all depends upon how "proof" is defined. Arbitrarily narrow proofs tend to stifle the ability to voice dissent and thus lock group thinking into static modes. At times, physics has managed to escape these boxes by diverging into different directions but at the expense of being able to link them back together holistically (which is why Quantum Mechanics, Special Relativity and General Relativity aren't entirely lined up - and why many other possibly theories are completely dismissed). 

• To expand a little on the previous point - non-physicists will note that in nearly all published explanations of any key aspect of Physics theory the proofs are tossed into the middle of the narrative. For outsiders, this almost appears compulsive in nature (as you rarely find any examples of where this doesn't occur). It has the effect of potentially excluding 90% of the world's population from the debate as it ensures that only those who have studied some physics are likely to brave all these proof-filled narratives. So the math becomes a barrier, and perhaps more of a barrier if the formal trade groups that control Physics (well, that's what we might call them) determines which proofs are allowed without much input from the majority of the members (and how they will be defined). This is justified by stating any wider results are invalid - this despite the volumes of conflicting and inexplicable data accrued over the past century - but more on that later. This proof-centric situation has the chilling effect of preventing the field from challenging its own core assumptions.

• Physics has been for past century more of an experimental than an applied science. This is changing and changing primarily due to IT. But as in R & D for IT, the experimentalist view of the world often becomes divorced from reality and the balance between research and application should always include a healthy portion of practice. 

• Like most experimental science, Physics is severely restrained by the tradeoffs associated in building, reproducible manageable results. What does this mean - it means that we too often build arbitrarily simplistic experiments that inevitably tell us only what we want to hear or worse yet give us a false impression of the problem. The best way to illustrate this issue perhaps to describe a typical medical experiment; a test group of patients is a given a new drug say for hair growth, another test group is given a placebo (let's say an M & M). The whole focus of the experiment then resolves around just two variables and the other variables are factored out. The problem with this though is that we know the real world doesn't work that way thus we can never be sure of the dynamics of what's coming out in the test results. 

I will insert more observations regarding the practice of Physics as we proceed in our series on time in the context of actual decisions and events regarding current theory. Our following articles will focus on some of the key questions that inspired modern Physical theory - the first being this: "What is light," and it's corollary, "Is Light a Particle or a Wave." These in turn will help us to understand the question most closely associated with our Use Case - "What is Time."

copyright 2013, Stephen Lahanas

Read More

Standardization versus Innovation

In yesterday's post, we discussed how the most common components of any Enterprise Transformation is usually a set of specific or tactical Standardization exercises. These exercises are meant to help:

1. Improve inefficiencies
2. Drive down costs
3. Enhance current capabilities

The third point here is key - most standardization efforts are directed at moving an organization towards commoditization of already well-understood, previously deployed capabilities. Now it so just happens that standardization efforts are also needed in order to facilitate migration to new capabilities as well (within the context of an Enterprise Transformation), so standardization does play a dual role in some cases. Often times standardization occurs separate from any larger Transformation initiative - a good example of this might development of standard desktop images or movement from traditional desktop management to virtual desktops. Now at first glance, it may seem as though the Desktop Standardization efforts are in fact facilitating enterprise innovation, but this is not always the case.

Virtual Desktops represent progress, right?

Today's topic deals with the more or less constant tension between Standardization and Innovation that exists within most enterprises. We'll use the Desktop Image Management example as our case study. So, let's step back for a minute and ask the obvious - why should Innovation and Standardization necessarily be at odds? The quick answer is this - IT moves between cycles of expansion and distribution to periods of consolidation and centralization. This has been occurring in one form or the other since the beginning of Information Technology as an industry. A good example of a current manifestation of this cycle is the movement towards Cloud Computing as a way to facilitate centralized management (or the consolidation of the data centers needed to provision those Cloud solutions).  

At the same time as Cloud solutions are making inroads, other more disruptive Mobile solutions are forcing a more distributive paradigm - although the hope is to link all of the new disruptive technologies through Cloud. The battle between "taking control" of the enterprise and "taking advantage" of emerging technologies never ends and it never will. The reason that this is the case is that each activity (standardization and innovation) has a somewhat different Use Case:

1. Standardization is primarily focused on optimization of existing capabilities
2. Innovation is primarily focused on exploitation of newer capabilities

As we pointed out earlier, there are ways to combine the two Use Cases together in the context of a larger Use Case (e.g. Transformation). There are other ways to do it as well, but we'll return to that in a minute.

So, let's examine the desktop case study again. How might we interpret the ability to centrally provision standard desktop images or do so using virtual desktop technology? Is the goal of standardization to:

1. Reduce licensing costs (for desktop software)
2. Simplify OS management, thus reducing Desktop management staff 
3. Make it is easier for the organization to build new applications and services and apply them to standard environments

or are the goals to...

1. Extend use of nonstandard devices by being able to centrally manage all sorts of OSs and OS combinations
2. Facilitate the development of systems that use more than the standard desktop or laptop hardware
3. Help to open up new business models or mission opportunities for the organization by supporting a flexible set of platforms?

The first set of goals are connected to the Standardization Use Case, the second to the Innovation Use Case. So, what happens if an organization chooses the first set and refuses to acknowledge the latter set? This often results in an innovation bottleneck; wherein only small amounts of innovative new capability can be absorbed into the enterprise - whether the larger organization wants it that way or not. And this is where it gets tricky, because often times decisions made to optimize or commoditize certain areas of IT that are seen as needing to be super-efficient can thus lead to severe restrictions in the ability of any part of the enterprise to be innovative. Worse yet, these conflicts are generally not understood or often not even recognized. The constraints and dependencies of a complex organization aren't generally what's communicated to senior leadership - CXO level folks are generally more interested in hearing where savings have been achieved. 

The problem is though, that more often than not the inability to reconcile the Use Cases leads to more losses than the savings gained in achieving super-efficiency if the enterprise fails to recognize what's really going on. 

Copyright 2012  - Technovation Talks, Semantech Inc.

Read More

Demystifying Enterprise Architecture - Part 1

What is Enterprise Architecture (EA); it is mysterious; it is complicated and often times it can appear almost artistic in nature. Information systems represent virtual capabilities; they are often grouped within interwoven boundaries or ecosystems referred to as enterprises. An enterprise architecture is generally considered to be a data driven visual roadmap to the system of systems enterprise. What does an EA really provide though, how are effective ones created and exploited? Why do so many attempts to develop EA’s lead to disappointment?

In these posts, we will examine the nature of Enterprise Architecture and the practical considerations as to why some work and others don’t. Ultimately, we consider ourselves strong advocates for this technique; however that doesn’t prevent us from taking a critical look at how the industry currently utilizes it and how the practice might be improved.

Enterprise Architecture can be viewed narrowly or can encompass all architectures within an Enterprise

Background
Perhaps the first and most famous example of architectural visualization in information technology is the Von Nuemann processing model. This was a logical representation of what later became a physical / hardware architecture in every computer ever built.  However, before the hardware was designed, the conceptual approach to the management of the processing logic needed to be expressed. The original diagram was likely drawn on the back of a napkin or envelope but the medium was not important – what mattered was the ability to clearly visualize the concept and within that visualization to also illustrate the logical workflow.

Many of you have probably already heard countless analogies comparing the construction buildings and the use of blueprints to the development of systems utilizing architectures. To some extent the analogy is accurate, but there are some important differences. Those differences include:

• A degree of subjectivity in information systems not present in brick & mortar construction
• A degree of complexity in information systems not present in brick & mortar construction
• An assumption of a greater degree of interdependence and inter-relationships between virtual components as opposed to physical ones. (to some degree this is becoming less differentiated as more information systems are integrated into core building operational functions)
• The realization that the virtual system can become cognizant that it is integrated within a global infrastructure (buildings are more locally oriented).

All of the factors listed above tend to point to a singular conclusion – virtual entities are not bounded, either by time or space or by capability, thus their potential for harnessing complexity or becoming mired in it is exponentially higher.

Many people trying to get a handle on Enterprise Architecture make a mistake early on by focusing entirely on one or more EA frameworks. EA frameworks are self-contained architecture paradigms including data models, notation and methodologies designed to address various aspects of EA or specific markets. You may be familiar with some of them; the Zachman Framework, FEA, DoDAF, TOGAF. While these frameworks are important and for some practitioners will be dictated as mandatory, none of them represent the entire EA lifecycle. As is the case for many areas of IT, specialization has become too specialized at times, making it difficult to see the big picture. And not seeing the big picture in EA is one of the primary reasons that it is rarely applied to its full effect.

Enterprise Architecture is more than the visualization of a technical solution; it is also the visualized roadmap of the development and operational lifecycles associated with the solution. EA that is used only to meet a mandate or to support a high level business design or to support only a system level technical design will fail to place those elements in their larger context. To understand how EA can be used to transform the management of your enterprise information system environment we’ll need to look at EA from several core perspectives:

•    EA as a unifying, organizational mechanism
•    EA as design framework
•    EA as interoperability framework 

Copyright 2012  - Technovation Talks, Semantech Inc.

Read More

Preview for Talk #1

Our first Technovation Talks presentation (coming this weekend) will be entitled: "Understanding IT Architecture - An Overview."  We chose IT Architecture as a starting point given its universal nature and the fact that it provides a vantage point for exploring most other Technovation topics. What is IT Architecture; how does it differ from traditional architecture; why are there so many types of IT architecture? We will address these questions as well as the core concepts associated with the field.

The mindmap below illustrates some of the basics associated with the topic. This presentation will also provide a jumping off point for a variety of related Overview and In-Depth Technovation Talks on architecture.

Technovation Talk 1 - Presentation Mindmap

You'll notice on this blog that we are fond of using illustrations to help reinforce concepts - this tendency comes directly from years of experience working in IT architecture and one of the most valuable byproducts of understanding the practice and tools associated with architecture.  All of IT is dedicated to problem-solving; even for problems that aren't traditionally viewed as IT issues, for example refer to the diagram below:

Architecture is well-suited to illustrating problem sets

As move deeper into more detailed IT Architecture Technovation Talks, we will provide contextual examples as to how architecture can be used creatively in real-world projects.

Copyright 2012, Semantech Inc. All rights Reserved 

Read More