Semantic Integration - The SI of Tomorrow

Currently when people use the acronym “SI” they tend to refer to something known as ‘Systems Integration’ or specifically to ‘Systems Integrators.’ However, the nature of what a 'system' is and how that concept is evolving are going to change the way that we look at this particular term in the relatively near future. I predict that within the next ten years, ‘SI’ in the context of information systems technology will primarily refer ‘Semantic Integration.’

The Evolution of Systems Integration

What I mean when I say that Systems Integration and the notion of Systems are evolving is that new design concepts and technologies are having a radical and disruptive influence on current integration practices, processes and design approaches. What was a ‘system’ under distributed computing environments is now undergoing a transformation – taking on aspects of both the distributed model used today and centralized models from yester-year. This is largely coming about due to the advent of Services Oriented Architecture (SOA) technology and design principles. It is important to note here that SOA, like Semantics, is a practice area based upon design philosophies and technical standards – the tools being developed in relation to those philosophies standards or applied to it are not the drivers for these trends. Folks who focus on the software tools only and not the underlying principles tend to run into many difficulties in implementing these types of new capability.

Our previous or current experience with System of Systems architectures is what led to the need for System Integration and Integrators largely as an afterthought or mitigating action in response to the need for rapid deployment of multiple, new distributed technologies. Most enterprises have spent the last twenty years playing catch-up in this environment and few are truly architected in any comprehensive sense of the term. System Integration is often a tactical activity – ensuring data passes between systems silos, connecting various applications point-to-point or through limited middleware capabilities, deploying portals and unified sign-on and security management and so forth. Piece by piece, an enterprise becomes more unified under this type of scenario, but at a cost – that cost is increased complexity and expense for maintaining non-standard integration.

The future is upon us; that future is just now promising something new – the ability to coordinate architectures across tiers, across federated domains and across all related lifecycles. The new enterprise can be viewed as a single organic system, consisting of dozens or hundreds of services that operate as a single unified yet dynamic entity that is often federated across geographic and logical domain or boundaries and orchestrated at runtime. This is SOA but it is more than SOA, because SOA doesn’t yet have the necessary philosophical framework for exploitation of Semantics to help achieve this enterprise unification. That’s where Semantic Integration comes into the picture. 

Semantic Integration is not a product, it's a new way to view Systems Integration & Engineering

What is Semantic Integration ?

Semantic integration is not is not confined to or restricted to the ability to operate or configure or utilize specific semantic technology or software packages. Semantic Integration represents a specialized field of practice dedicated to using Semantic Design Principles, Methodologies and technology as a facilitating mechanism (often alongside SOA) to help solve enterprise-level problems for IT. SI as a practice area is relatively new (it is only now being defined),  it is much more than the “Semantic Web” yet is obviously built upon the capabilities inherent within the emerging set of Semantic standards that can be used to express and ultimately visualize semantic entities, RDF, OWL and so forth). Over the next several months, I will introduce the specifics of this emerging practice discipline in this Blog. 

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

Newsweek is Dead, Long Live NewsBeast?

This morning the New York Times announced that Newsweek would cease publishing the print version of its magazine in December. Is this the end of an era or the beginning of a new one? Should we feel happy, sad or indifferent?

Did Innovation, (like the iPad) kill Newsweek?

Two years ago, Newsweek, in  prelude to today's announcement had already merged with the online News Magazine, the Daily Beast (actually Daily Beast bought it for $1 dollar in 2010). Now, this merged online entity will be all that's left of the Newsweek brand. However, if you happen to visit the newly merged NewsBeast it seems a lot more Beast and a lot less Week. It doesn't even have its own dedicated Newsweek URL and the format looks little like a magazine and much more like a blog (which is closer to the core Newsbeast format and somewhat similar to Huffington Post but without so many pesky mini-blogs).

So what happened to Newsweek? What has led it to this juncture? Is there any hope that something like Newsweek will reemerge from the belly of NewsBeast?

First, let's look at the "why." While many folks seem to blaming recent management of the magazine, the reasons why Newsweek failed go back much further. Anyone in the print media business could see clearly in the late 1990's that the traditional print business model was on its way to extinction. That's not just because more people were going online to get their news - it's also because of the massive overhead associated with producing either daily papers or weekly magazines. There was very little profit margin to begin with and the instant that ads began peeling away from print and into online sites like Craig's List or even Ebay that was it - game over. It was only a matter of time before the traditional model collapsed because the revenue stream had been diverted.

So, how come the folks at Newsweek are now essentially out of business? There was a Newsweek.com at least until 2010. Didn't they (and the they in this case is the Washington Post Company) do what they needed to do to save the magazine and the brand? In a word, no. Here's what they did do:

• They launched their site at the right time, 1998 but starved it.
• They considered their print business an online business to be different and possibly mutually exclusive business entities, running under different business models.
• They failed to devise a transition strategy that would have moved the print model over to the online model in an orderly fashion - without that strategy they were prone to make some really terrible decisions.

 What were those decisions?

1. Selling Newsweek for a dollar despite having one of the strongest global brands in journalism.
2. Merging Newsweek.com with daily beast and shutting down the URL. They managed to lose the magazine and brand in one fell swoop with that decision. 
3. Finally, shutting down the magazine (this year) with essentially nowhere to go for the loyal readers - in effect they've committed brand suicide.

What could have been done differently? Well, here's some thoughts:

• The owners of Newsweek could have gradually invested more in its online future, making that its strategic priority.
• They could have viewed the Internet as an opportunity to redefine their business model, through partnerships and through media convergence. For example, why didn't they launch Newsweek online radio or video segments? Why not try more interactive approaches w/ Blogs like the company that bought them out? All of this boils down to an inability to provide a vision regarding what magazines ought to become in the 21st century. Instead of leading that charge, Newsweek was buried under it.

So, is the death of Newsweek a bad thing? Perhaps not so bad but disappointing; there was so much potential for it and to some extent it had taken steps towards realizing that potential (with millions of online viewers by 2010). However, the vision that was needed to move from a proof of concept to a new reality never materialized. 

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

Whatever happened to SOA?

Not too long ago Service Oriented Architecture (SOA) was the hottest IT trend around, at least if measured by the sheer amount of attention or hype that was associated with it. The fate of SOA is interesting for a number of reasons:

• It helps to illustrate the nature of Hype Cycles in IT and how they influence both industry and individual enterprises.

• It helps to provide context for why Cloud solutions have now become the "killer solution" (it can't be described as an app) that most folks are examining today.

• It is an interesting case study in regards to the difference between product-based Hype-Cycles and architecture or standards based hype cycles.

So what did happen to SOA? Strictly speaking, it's still around and going strong, however it is no longer at the top of the 'must have' or 'must do' lists in most IT departments these days. Many SOA initiatives took the bridge to nowhere or have been merged into newer or perhaps more specific enterprise goals and objectives. Before we go any further though, let's recap what SOA represents:

1. SOA is not limited to one product or product family.
2. SOA encompasses both capabilities and process.
3. SOA is very focused on a key set of (mostly W3C) interoperability standards, notably SOAP, XML, WSDL and UDDI.
4. SOA is not merely a solution but also a solution strategy and architectural approach. This last point is both critical and very subtle. 
5. SOA has an systems integration focus, not merely a software development one.

This diagram illustrates a number of the Use Cases associated with SOA Adoption

 Each of the last five points is important and several of them are relatively complex issues. Essentially, taken together they tend to imply that anyone wishing to deploy SOA in a significant way would in effect be attempting some form of enterprise-wide transformation. That's a big deal regardless of the technology or technological paradigm targeted in the transformation. Change is never easy - it's less so when dealing with an entirely new way of managing your IT portfolio. These are some of the reasons that SOA is not the driving force in industry it was just four years. So, let's look at what did happen with SOA:

• SOA was and SOA is hard. There's no silver bullet solution - all options require a lot of work and some risk.

• SOA initiatives usually become Systems Integration exercises. Many providers or organizations without that systems integrations background attempted SOA solutions and quickly realized it's a skill that takes years to develop (both personally and organizationally).

• There's more than one way to do SOA - in fact there's quite a few ways. This implies a wide array of possible tools or software options. Navigating those decisions is confusing to say the least and since this happens up front it often short circuits projects before they ever get off of the ground. There's not one piece of software associated with a proto-typical SOA solution.  

• Often times key elements of SOA infrastructure are not implemented as part of an initiative. Common examples of this include failure to deploy a SOA Registry or Governance paradigm. This tends to limit the effectiveness of the solution and eventually restricts the scope of the entire solution.

One of the reasons people were initially enthused about SOA was that it seemed to represent an easy path to bypass many of the ills associated with the ad hoc heterogeneous sprawl that had become the typical IT enterprise by the mid-2000's. That initial assessment was a misconception, but so too are similar assessments being made now about "Cloud Computing" and "Big Data." Behind the Hype and the marketing buzz, there are certain underlying problems that all IT trends are focused on resolving. More often than not however, no single trend is positioned to solve the challenges alone. We will talk more about Cloud Computing, Big Data and SOA in future posts and presentations. Also be sure to check out our Technovation Glossary page.

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

The Architecture of Debate

Tonight marks the second presidential debate in election 2012. Many people are thinking about who will perform and who won't, but how many are talking about the architecture of this week's debate? Sounds a bit strange doesn't it; but believe it or not one can apply the principles of Architecture to just about everything and Debate is no exception. What this statement implies is that there is in fact an organized structure behind every debate (despite whatever performances are turned in by the candidates), and several structures if you really think about it:

1. The structure of the debate event itself; the rules under which the participants agree to follow (or not as was the case in this year's first presidential debate).
2. The structure of each participants core positions or arguments.
3. The structure of the attacks by each participant on the others positions or arguments. 

What Keywords will you catch in tonight's debate?

As we stated in a previous post, Politics are based primarily around information and communication; so it stands to reason that a debate in some sense resembles an information architecture. The determination as to who wins a debate is a fairly subjective exercise; what can be measured perhaps is how "well-architected" their approach (and delivery is). So what does that mean? If we look back at the three main components of Debate Architecture listed above then we might provide some subjective measures based upon:

• Whether the candidate / participant was able to work effectively within the rules; e.g. were they able to provide arguments and responses within the allotted time-frames or did they constantly run over time. Were they able to get their point across within their own sections or did they feel it necessary to interrupt the opponent/s during theirs?

• Did the participants' arguments make sense; either in the context of their political ideology, their platform or the precise questions being posed during the debate (and hopefully across all of these contexts).

• Were the participants able to respond or defuse their opponents' arguments or did the participants simply talk past those - perhaps repeating key phrases or slogans that address the topic generally but not the specific arguments made during that debate.

How did they do last week? It depends on how you measure it...

These are just some of the ways we attempt to assess the outcomes of debates. If we were to take it a step further, perhaps we could even diagram some of this out. For example, we might consider that each argument or political theme has multiple dimensions; for example a political one, an economic one and a personal one.

• The Political Dimension – This represents how people view their government as well as political values & philosophies.

• The Economic Dimension – This dimension represents how people view economic policy and philosophy.

• The Personal Dimension – This dimensions captures the personal expectations of constituents as well as a general sense of what the “individual” represents within a society.

Not every argument or issue will span all three of dimensions but surprisingly most of them do. For example, one might think that a social issue ought to reside primarily in the personal dimension but what if part of the argument addresses government regulation of that social issue and another directly affects national or state budgets?

An Ontology can provide an organizing framework for all information associated with a domain

Arguments can be built using Dimensions at a high level, but what about at the the detail level? That's where having an organized approach to managing a large set of complex and inter-related knowledge comes in very handy. One of the best ways to do that is through use of Ontology (see the illustration above). Who knows whether either candidate will bring their A game tonight - but perhaps the real question is - do they have a game plan?

Copyright 2012, Semantech Inc. All rights Reserved 

Read More