Cyber Security Predictions for 2017

2016 was a big year in the annals of Cyber Security, and 2017 promises to eclipse it.

Creating an Enterprise Data Strategy

An introduction to the process of developing comprehensive strategies for enterprise data manangement and exploitation.

A Framework for Evolutionary Artificial Thought

Let’s start at the beginning – what does this or any such “Framework” buy us?

The Innovation Dilemma

What things actually promote or discourage innovation? We'll examine a few in this post...

Digitial Transformation, Defined

Digitial Transformation is a hot topic in IT and big money maker for consultants - but what does it really mean?.

Showing posts with label methodology. Show all posts
Showing posts with label methodology. Show all posts

Saturday, June 1, 2013

Deconstructing Time - part 2 "Events"

In the last post, I introduced a new line of dialog for Technovation Talks and provided my own "frame of reference" for how the investigation may proceed. This post will be used to begin quantifying Time. I think most people probably have a sense that this is something that has already been figured out. However, the deeper you dive into the topic, the less clear it seems to get. And any lack of clarity would make it difficult if not impossible to create reproducible mechanisms for identifying events.

We'll start by defining "Event."

Here's the Wikipedia definition:
In physics, and in particular relativity, an event indicates a physical situation or occurrence, located at a specific point in space and time. For example, a glass breaking on the floor is an event; it occurs at a unique place and a unique time, in a given frame of reference. 
Strictly speaking, the notion of an event is an idealization, in the sense that it specifies a definite time and place, whereas any actual event is bound to have a finite extent, both in time and in space. One of the goals of relativity is to specify the possibility of one event influencing another. 
I'm focusing on Events to begin with because I believe this is perhaps the most likely way to help identify paths and or coordinates within spacetime. The use of the term Event in this context is generally associated with the modern view of time - e.g. time as described in the context of both Special and General Relativity (although surprise, surprise Einstein's two theories don't exactly agree with each other on this topic and neither of them have been reconciled yet with quantum physics). Events are also mostly ignored in the previous accepted paradigm defined by Newton  - known as Absolute Time. Here's how Sir Issac described it:
Absolute, true and mathematical time, of itself, and from its own nature flows equably without regard to anything external, and by another name is called duration: relative, apparent and common time, is some sensible and external (whether accurate or unequable) measure of duration by the means of motion, which is commonly used instead of true time.
nice scarf, Issac...
It's worth noting here that there was disagreement on this definition almost immediately after it was introduced and that debate was one of the key factors in helping to drive modern theory. So Newton accounts for the possibility of events but relates them to what he calls "common time." Interestingly, also he contends that absolute time is independent of motion, sort of an a priori view of time - time is as time may be defined in its own right, or time as a constant.  A constant is a measure - but an event is that which is measured which is why we're starting there.

Beyond the initial description of what an event is an abstract sense, there isn't any agreed upon definition as to what an event in physics actually represents. Without that understanding that it is highly unlikely that we could ever define precise/distinct events or come close to pinpointing them in any sort of consistent fashion. So let's revisit the definition of an event by first attributing some more characteristics to it:

  • An event is dynamic. In other words, there is no standard duration or scope bounding any given event.
  • Events can occur at multiple levels of context. This can extend from the subatomic level up through to a universal scale. Those levels of context can become a more or less de facto Event Taxonomy.
  • Events are grouped within reference frames, those frames inhabit all levels of context (in varying sizes).
  • An event requires at least one entity and in most cases two in order to occur. (I'll explain this is more detail later - situations with only one involve humans).
  • An event involves some interchange of energy. On the atomic scale this could be visualized as electrons colliding, on the cellular it could be white blood cells engulfing bacteria and absorbing their energy or on our scale it might be more subtle - one action impacts the causality chain of others (some within the same frame of reference, others outside of it). There is the possibility that this interchange may provide some sort of identifiable signature (not unlike some of the phenomena we search for in subatomic physics when looking for new particles we think exist but haven't captured or detected yet).
  • All events have a beginning and end point, however events can overlap and events can be chained together in a variety of different ways. Event chains can also follow distinct trajectories within timespace called "event paths" (or 'continuity paths' - more on that later).
  • Events occur within a given time phase (that phase is a combination of a number of factors including frame, context and information velocity).
  • Measuring an event impacts or changes that event. In other words, the Heisenberg principle applies. 
  • The duration of an event is dictated by the duration required to complete any given interaction or set of interactions. 
  • No two events are exactly the same. 
  • Events inhabit a specific, definable region of spacetime - however this region (or set of coordinates as the event moves along with spacetime) cannot be accurately identified using the current method for assigning location in 4 dimensional spacetime (4 vector coordinates - more on that later).
  • Human perception adds a number of complications to the nature of events that must be resolved if we ever intend to develop consistent framework for understanding them. For example, determinations of how to group or separate events will at first be a somewhat subjective exercise - as an example of that I've included an illustration of a somewhat arbitrary framework for doing it directly below.  
  • If we accept some of the key precepts of relativity and current evidence it is clear that events from past, present and future can exist in one simultaneous frame of reference, at least indirectly (more on this later).
  • Events exhibit simultaneity - in others words, the entities within it share a 'now' which is defined by the ability to synchronize information across / over the span of the event. This is typically described in physics as the ability to transmit information using light thus it is bounded by the C or constant speed of light.  

This represent a potential way to stack or organize events...
Based on these characteristics then, here is a somewhat modified base definition for "Event:"
An event is an identifiable portion of spacetime, characterized by the interaction of entities within its scope of relative simultaneity.  
I've noted that scope is bounded by relative simultaneity for two reasons:

  1. That for human entities / observers, simultaneity can extend to significant distances through use of technology. (more on that later). 
  2. That at the Quantum or subatomic level, (and potentially at the universal level) information exchange is not restricted by C. 

In our next post we talk a little bit about travelling to a nearby star and its implications to our views of spacetime and introduce reference frames in more detail.



copyright 2013, Stephen  Lahanas

Deconstructing Time - part 1

We're going to expand the scope of our examinations here on Technovation Talks to include dialogs on more fundamental topics related to science, technology and innovation. We will begin this new chapter in our blog by launching a discussion about Time. This dialog will investigate both current thinking and its gaps as well as the technological implications of our ever-evolving understanding regarding the nature of time.

Deconstructing Time - Part 1: An Introduction
I tend to work as a consultant - the scope of that work encompasses Information Technology, but the methodology and nature of that type of work can be applied to any problem space. In my opinion, the type of methodology we tend to use today in most IT projects is considerably more flexible (or Agile) than those used for most other professions. This wasn't always the case. From the 1950's to the 1980's Information Systems (IS) as a practice area was much more rigid. The reason why it was more rigid was the relative pace of innovation, which during that time period was substantially slower than it is today. If we were able to plot both quantity of technological change and the rate of acceleration of that change would become even more obvious why less rigid thinking was needed. Beginning in the 1990's, the pace of change reached a critical mass - IS became IT - and this lead to an explosion of jobs in the IT field and the introduction of many people who hadn't initially viewed IT as a career opportunity.  

From the perspective of this new influx of people, the attraction to this evolving field included:
  • The ability to define technology.
  • The ability to help define new fields of practice. 
  • The freedom to think 'out of the box' - creativity is rewarded in IT now more often than it is in most other fields.
  • The ability to apply IT to help redefine everything else in society. 
IT is the place to be for people who want to exercise innovation on a regular basis. I'm not saying that innovation doesn't occur in other fields, it certainly does, the difference may be in how hard one has to fight to achieve it elsewhere as compared to IT. The phenomena behind what I'm describing is not unique to recent history - it simply reflects the nature of collective consensus - in other words once key concepts are well defined, a community unites behind them. Concepts become 'institutionalized' and entry into the community (of practice) requires adherence to those concepts. Questioning the foundational concepts of the group is generally discouraged - or at the very least only permitted within restricted parameters. IT stands out today in that entry into the group is very informal and questioning of premises is tolerated because the premises or fundamental approaches are in a constant state of flux.
So, what does all this have to with Time? Well, what I'm proposing in this series of posts is to reexamine current assumptions in regards to how we view Time as a construct and to apply my IT-related methodology to that 'problem space.' This is both a theoretical and practical exercise. It's theoretical because we are challenging and hopefully changing some key assumptions and practical in that this modified world-view will have a number of practical (and maybe not so practical applications).

Disclaimer - what will follow in this series is a layman's description of the problem space; the intent is not to provide mathematical proofs but rather to illustrate conceptual alternatives. This is not altogether different than how I would approach a problem strictly associated with IT (we don't express design logic in binary format or assembly language but rather through the abstraction the design elements into conceptual or logical terms).

We will use a tailored or specialized version of our typical IT methodology - it is based on assessing topics in the context of problem space. Our problem space for this exploration is complex time-space coordinate mapping or travel. The central question is this - how does one locate an event in time/space?  In order to answer this, I've constructed an approach through the following steps:
  1. Re-examination of core assumptions regarding time (or TimeSpace). The expectation is that this will lead to some redefinition of the topic matter.
  2. Determine of an approach for coordinate mapping for event location. 
  3. Assess current (design) patterns for travel within SpaceTime.
  4. Create updated patterns for travel within SpaceTime.
  5. Explore potential applications for the modified assumptions and new patterns.

Our segue into the following post is the definition of Time itself. What is it? Here's what Merriam Webster says:
Measured or measurable period. More broadly, it is a continuum that lacks spatial dimensions. Philosophers have sought an understanding of time by focusing on the broad questions of the relation between time and the physical world and the relation between time and consciousness. Those who adopt an absolutist theory of time regard it as a kind of container within which the universe exists and change takes place, and believe that its existence and properties are independent of the physical universe. According to the rival relationist theory, time is nothing over and above change in the physical universe. Largely because of Albert Einstein, it is now held that time cannot be treated in isolation from space (see space-time). Some argue that Einstein's theories of relativity vindicate relationist theories, others that they vindicate the absolutist theory. The primary issue concerning the relation between time and consciousness is the extent, if any, to which time or aspects of time depend on the existence of conscious beings. Events in time are normally thought of in terms of notions of past, present, and future, which some philosophers treat as mind-dependent; others believe that time is independent of perception and hold that past, present, and future are objective features of the world. See also geologic time, Greenwich Mean Time, standard time, Universal Time.
Other searches will trawl in many more definitions; dozens, even hundreds of them and of course many books have been dedicated to the subject. But perhaps some of these definitions are too complicated to get the topic started  so let's identify characteristics that tend to be related to Time in one fashion or another; these include:
  • Time is something that is perceived.
  • Time is something that is measurable.
  • Time seems to be related to space.
  • Time seems to be related to motion, distance and velocity.
  • Time may be relative to the perspective from which it measured or perceived. 
  • Time appears to be linear.
  • Time has both 'local' and 'global' contexts - e.g. it seems scalable.
  • Time may or may not be a physical construct.
  • Time seems to break down at both the subatomic and universal scale (e.g. big bang)
The next post will take a deeper dive into the definitions of Time.



copyright 2013, Stephen  Lahanas

Thursday, October 11, 2012

What's in a Name ? - "Enterprise Architect"

Enterprise Architecture is a new discipline within the Information Technology domain. Few if any university level programs adequately address the skills required to work as an EA. Perhaps sometime soon there will be degree programs focused on enterprise architecture – perhaps not. The vast majority of people who work in the field as EAs are self-taught and often work in other IT disciplines as well. All Enterprise Architects began their careers doing something else.

Enterprise Architecture also represents the apex of technical positions within IT – both in terms of career status and usually in terms of compensation. It represents an alternative to management as an ultimate career goal (e.g. the inevitable interview question – where do you see yourself in 5 to 10 years). It serves this capacity because it allows IT professionals the opportunity to apply their expertise and experience in high profile roles that often are responsible for leading critical enterprise projects.

What is somewhat confusing is the fact that enterprise architects aren’t always referred to as such or may be shifted back and forth between enterprise and project roles. It is helpful to view architecture within its continuum – that continuum is separated mainly by scale or scope:
  • Level 1 – Technology Specific Architect (many to 1 – project or enterprise)
  • Level 2 – Solution or Project Architect (many to 1 enterprise)
  • Level 3 – Enterprise Architect (may be more than 1 per enterprise based on domain responsibilities with a Chief Architect as lead).
Other roles that are sometimes asked to perform EA tasks include:
  • Systems Analyst
  • Business Analyst
  • Data Analyst
  • Systems or Chief Engineer

So that begs the question – what types of tasks is an Enterprise Architect asked to do? Here is a brief list (by no means meant to be comprehensive):
  • Determine enterprise workflow models.
  • Perform enterprise technology and architecture assessments.
  • Create EA views using one or more EA Frameworks (ToGAF, DoDAF, Zachman etc.)
  • Provide Transformation Blueprints (ERP, SOA etc.)
  • Create Enterprise level Ontologies, Taxonomies or Master Data Frameworks.
  • Determine Data Center Configurations and Processes.
  • Design Network Architectures
  • Design Data Architectures
  • Design Application and Service Architectures
  • Solve Problems
  • Integrate multiple architectures / technologies
  • Design products and services
The technologies and tools change. Often, the exact nature of the role changes as some aspects of the work are shifted to specialists (can be solution or technology architects) or as new disruptive technologies or challenges require attention. The Enterprise Architect is the first line of defense against complacency and the number one agent or facilitator of change in any organization.

An architecture assessment methodology, like the one above, can be applied to any technology...


The EA is a technologist, first and foremost and must necessarily spend much of their time understanding and learning new technologies. The EA must also never lose sight of the realities involved with actual implementation of higher level strategic designs and directives. It is perfectly reasonably and highly recommended that from time to time the EA should take more specialized roles to make sure they don’t lose touch with the difficult details associated with real world projects. The EA is a generalist who has the ability to be a specialist in any number of areas (and in fact probably was before moving to EA).

The enterprise architect is someone who is comfortable extending their boundaries – pushing the envelope. If you’re the type of person who doesn’t like constant change or challenge than enterprise architecture is the wrong career path. An EA is someone who doesn’t assume they always have the right answer – but is dedicated to finding it regardless of the difficulty involved.


Copyright 2012, Semantech Inc. All rights Reserved