The Growing State of Cyber Insecurity

2014 will likely be marked as the year that the warnings from the past decade about Cyber threats were finally realized. Granted, not all of those warnings have come true, yet - but this year will go down as the worst yet for costly Cyber breaches. That begs an important question - why are we becoming less secure as time is passing - and why haven't the billions of dollars invested in Cyber Security worked?

This is a complex topic, so it will probably help to provide some high level context. We'll start with some definitions:

• Security Architecture - the practice of actively designing security into complex systems or environments.
• Intrusion Detection - the backbone for most perimeter-focused security solutions; focus is detection / prevention of breaches.
• Threat / Vulnerability Management - the practice of tracking and adapting to specific threat vectors (attack signatures, exploits etc.)
• Security Controls - usually standards-based system & process framework for assessing, securing and auditing security status.
• Social Engineering - the practice of using non-technical persuasion or other techniques to gain information in order to access secure environments.

Now, let's ask the question again. Target, Chase, Sony Pictures - why is this year the year of massive security breaches? What went wrong?

There are 5 top reasons that this is happening; I'll introduce them together and then explore each one in detail later.

1. It is easier to Cyber Attack than to Cyber Defend and likely always will be.
2. Cyber Security is not viewed from a holistic perspective in most organizations today - this includes many military organizations.
3. There is no one magic bullet technique or technology that can secure an organization - yet we spend a lot of our time looking for one or thinking we have one.
4. Just as we secure one aspect of the enterprise, 3 new ones pop up that aren't secure - and in many cases each of these offer attack routes back through the areas we thought were secure.
5. Cyber Security represents an intersection between (human) behavior and information patterns. We haven't yet resolved either of these issues separately yet and we definitely aren't close to dealing with how they intersect.

a representation of pattern identification in Cyber Attacks

So, who am I to discuss such matters? I'm not a recognized Cyber Security expert that's true. I'm just an IT Architect. But, I'm an Architect who has had the privilege of working on some fascinating Security related projects over the years; my first ones were in 1998 and 1999. In 1998, I worked on a research project for the AF to help develop a next generation Intrusion Detection system - we called it the Secure Adaptive Network Environment (SANE). As you can tell, it is was perimeter and data center focused. The second project was much more ambitious, I was brought in as a security architect (from the AF perspective) for the first iteration for GCSS-AF, which was and still is a large data center consolidation, application hosting initiative (now much of it is Cloud-based). Both of these projects helped (for me anyway) to illustrate a number of the key problems that would be associated with Cyber Security for the coming decades (although back then we didn't call it Cyber Security yet). Some of those observations included:

• The notion that the landscape was going to get ever more complex
• The need for unified access control (directory services as well as application logins etc)
• The need for various levels network security (which was in fact already deployed in the DoD) as well as encryption across public networks
• I saw how easy it was for dedicated enthusiasts to breach most systems they set their sights on (sat in on a few of the first 'hackathons')
• I saw that static or reactive security was the standard operating approach behind most perimeter based security approaches and it was never going to work
• I saw that we in the business we spending way too much time focusing on the products that were supposed to make us secure rather than understanding or controlling the holistic processes necessary for real security.
• And then there is all that log data - which was only going to grow and grow until it would become unmanageable.
• It was obvious that Cyber Space would become another 'field of battle' alongside air, ground, water and space. There would be both state-sponsored and free-enterprise focused organized cyber cadres. These groups have had nearly 20 years to mature in 2014 - the future of Cyber Security was not individual hacker like Neo (from the Matrix) but Cyber crime syndicates and armies.

Ten years after these initial security projects, things were developing pretty much the way I had anticipated. If anything, things may have developed slower than I had anticipated - in terms of the numbers or severity of the breaches happening in 2008 / 2009, but the trajectory was definitely on track. I thought the time was ripe for moving to the next stage of Cyber defense, but remarkably, I found quite a lot of resistance to the notion of taking a holistic view of Cyber Security, so I moved on to other my productive arenas.

Example of a Cyber (Defense) Collaboration approach across organizations

Holistic Cyber Security is of course where things have to go and the answer to what's missing. Let's look at each of the five issues I identified above in more depth:

1. It's easier to attack: Why should this be the case? Well, the tools that Hackers, Crackers or rogue Cyber syndicates or armies use are less expensive and less complex to use than the tools we use to defend assets. A hacker can get started with almost no investment while each component of a let's say a perimeter defense architecture may cost millions and take months to implement. Worse than that though is that attackers work as a collaborative community - which means they can collectively share information on how to defeat that new defensive technology and eventually we end up playing a reactive role - fixing vulnerabilities only after they surface. This situation is unlikely to change under current defensive paradigms.
2. Piecemeal Security: That's the opposite of holistic isn't it? Think about this. Every IT capability in a modern organization represents a potential threat to security. Whether we're talking about a Cloud, a mobile app, an edge device that needs to be secured, data in motion, applications (web based or otherwise), files and documents, email, portals etc.,etc.,etc. And usually all of these things are not managed by the same groups within an organization and often many of these things aren't considered as part of the security landscape at all. Most of the focus for Cyber Security in today's enterprise is still hovering around the perimeter and network. While this part of the picture is important - it is not the whole picture and never was; not in 1998, not in 2008 and certainly not now. On a recent 60 Minutes report, a famous security expert mentioned an even more telling aspect of this problem - even at the perimeter there is now so much information being generated there is no way to discern what are the real threats. We'll talk about that more in a minute.
3. There is no magic bullet: This is a bad habit shared by other aspects of IT, but for Cyber Security this thinking is particularly problematic. In the late 90's and early 2000's the magic bullet was Intrusion Detection and Firewalls. Then there was PKI and host of other encryption protocols and products and of course anti-virus software has become more and more pervasive since the late 90's. Even the notion of security standards or controls has been viewed as a magic bullet, but the fact is whether it is processes, standards or products - all of these elements represent 'part' of a larger picture. That larger picture needs to begin with deliberate Security Architecture on an enterprise scale.
4. Cyber Security is Dynamic: Yet most security organizations and products aren't. We understood that all the back in 1998, which is why we began building community contribution of exploits into Intrusion Detection products. Collaboration on the defensive side is there, but it still isn't as effective as the collaboration on the attacking side; mainly because the job of the defenders is many times more complex. Becoming dynamic is no small task - it requires a paradigm shift in thinking for most organizations and thusfar it is very rare to see it in practice.
5. Cyber Security is Information & People: A proactive approach to security requires the defenders think like those who might attack them and predict or identify weakness. It requires the ability to discern or predict patterns in the ever growing sets of data (just as was highlighted on 60 minutes). This simply has not happened yet. Despite some progress with Security Controls and Vulnerability / Threat Management, we are still largely operating in a reactive mode. We don't have a good handle on stopping insider attacks or understanding threat behaviors.

In some ways, we've been lucky so far that the Cyber attacks have been primarily focused on stealing information or financial data, rather than attacks on systems dedicated to infrastructure. While many of those systems are somewhat more secure by design, they are not as secure as we might think (just as the breaches this year have called into question the efficacy of security associated with PCI standards and finance-related systems). We are becoming more Cyber Insecure because we are not as adaptive as our opponents and because we still refuse to recognize the full scope of the challenge. In many cases, we are spending perhaps exactly as much as we need to - but we're not spending it the right way or in the right context. We're paying for piecemeal security and unfortunately that's what exactly we're getting.

copyright 2014, Stephen Lahanas

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

Can Enterprise Architecture be Agile?

We're taking another break today from Physics to talk about IT innovation again. IT practice changes quite a bit and certain practices come and go. About 10 years ago, Enterprise Architecture (EA) surged to the forefront of the IT community primarily because it was adopted as part of the key acquisition processes connected to the Federal Government. The law that brought this about was called the Clinger-Cohen Act and it provided portfolio management expectations for IT which were designed to help avoid large-scale IT project failures (ones costing the taxpayers more than $100 million) but also applied to all IT investments. Not too long after this law was passed in 1996, the Department of Defense and other agencies redesigned their IT processes / methodologies to become compliant with Clinger-Cohen. Soon after that the practice of EA became very much in demand.

EA was around before this of course, namely through the introduction of the Zachman framework in the late 80's, early 90's, but most organizations hadn't adopted it yet. The federal mandate provided an excellent incentive both for federal and commercial adoption. It also created some issues however, namely that much of the early work in EA became tied to a more procedurally intense form of practice - in other words, to many it seemed to be a bit bureaucratic in nature. The perception quickly became that EA was not an easy undertaking or something that could be used to produce quick results. This is similar to what happened to E-learning at roughly the same time for about the same reasons - government adoption and stewardship was both a blessing and curse to the industry.

So the following question is now often posed within IT in regards to Enterprise Architecture - is it possible for EA to be Agile? In most quarters, the immediate reaction would be a resounding - no. But perhaps maybe we're being too harsh in our initial judgement. First, though, we need to define what Agile would mean in an EA context:

1. It would require rapid turnarounds for designs and decisions.
2. It would require the ability to integrate both with traditional (waterfall) methodology and Agile development methodology.
3. It would need to support and promote collaborative problem-solving within the organization using it. In other words, an EA group doesn't become another island or silo, it is the mechanism that bridges all of the silos.

Based on these definitions, EA can and definitely is Agile if practiced correctly. The following articles provide examples of how various aspects of EA can be integrated within an organization and remain Agile:

• Aligning User Stories, Use Cases and Requirements
• Integrating Design & Architecture
• SharePoint as an Architecture Repository

EA provides the superstructure within which all other enterprise capability resides and interacts.

Many of the articles included in this blog were produced from projects that followed an Agile EA approach, including the Intelligent Healthcare framework, Semantic COP and Governance as a Service. I've applied Agiel EA in the following domains thusfar:

• Defense
• Aerospace 
• Healthcare
• Retail
• Manufacturing 
• Finance

I've also applied to the following IT focus areas as well:

• Cyber-security
• Data Management
• Services / application design
• Portal / CMS

So returning to the original question - can EA be Agile - my answer is yes. The key to making that happen involves the following assumptions:

1. Clearly defined expectations for the both what the EA group or architect must accomplish.
2. A willingness to improvise rather than following industry patterns or methodologies too closely.
3. The ability to work to deadline - to engineer a design around the constraints.
4. A willingness by the organization to allow the silos to actually work with one another (with an architect as mediator) - this is far less common than you might imagine.
5. The ability to develop architecture that is easily translatable and traceable to implementation level designs. In other words, alignment of all design related efforts must be built into the Agile approach.
6. The ability to make decisions quickly. 
7. A willingness to experiment. Many architects and organizations make the mistake of separating EA into a logical or somewhat abstract exercise and not allowing it to be involved in actual prototypes or POCs. The best way to ensure that key design decisions make sense is through an understanding of the technology in question.

We will talk more about how EA is practiced or ought to be practiced in future posts...



copyright 2013, Stephen  Lahanas

Read More

Integrating Design & Architecture

We're going to take a short break from Physics and dive back into IT - actually pretty soon we will see them intersect in our discussions - but for now we're going to expand on a topic I introduced on Dice.com last year: Integrated Design.

Many people view design work and architecture within IT as separate disciplines and perhaps as many different disciplines. It's my firm belief that all design-related effort (and architecture most definitely falls into that bucket) are related and contextual. The challenge of course is finding a way to integrate these activities - first from a process perspective and eventually through some sort of automation. One of the best ways to achieve this is through the development of an Integrated Solutions Framework.

One of the interesting characteristics of most Enterprise Architecture frameworks is that they are built atop meta-models. Those meta-models are in fact usually a 3NF (3rd normal form) relational data model (or ERD – entity relationship diagram). Having the models allows for the ability to deploy design artifacts to architecture repositories – it also provides a metadata framework that allows for reporting based upon the information resident within the designs. But most importantly perhaps, this illustrates how important it is to have a logical “mapping framework” for all information related to design. While using one of those frameworks within an actual software solution dedicated to architecture management is nice, it isn't necessary. One can recreate the logical framework as an organizational construct and still receive quite a number of benefits from it.

Here is a visual representation of what that standard framework might look like...

A prototypical framework for integrating design and architecture

In the following sections, I will provide potential benefits and explain the framework in more detail.

Benefits:

• This framework provides a clear linkage between specific elements of the architecture/design and requirements.
• This framework allows for consistent and logical descriptions of all solution elements across and within a given organization (and is scalable across organizations as well).
• This framework allows for management of all non-architecture designs alongside formal architecture deliverables. This is extremely important as in most organizations the majority of IT design is not captured as architecture (and in some organizations, none is).
• This framework can be used with no automation, some automation or total automation – it is also easily translatable to most EA frameworks.
• This framework can be integrated with / into any solution methodology and any standards management paradigm.

Levels (vertical):

1. Enterprise
2. Segment
3. Capability
4. Detail

Concepts (horizontal):

1. Design Activity or Description
2. Design Deliverable
3. Example/s

Definitions:

• Core / Holistic Architecture – The Holistic Architecture can exist potentially at several levels – it is roughly equivalent to an Enterprise Architecture (EA). Like an EA, the Holistic Architecture can encompass one or many domains and organizations. The main idea is that within some defined boundary the Holistic Architecture covers the comprehensive solution in question.

• Architecture Tier - An Architecture Tier tends to represent a logical layer within a holistic solution – for example this could be the shared Cloud Hosting environment that all other elements of the solution reside within. 

• Reference Architecture– A Reference Architecture can be a tier (more horizontal) or it could be a vertical segment (crossing tiers) within the larger Holistic solution. For example, a BPM workflow capability may stretch from to the infrastructure level to the User Interface and be considered the standard approach towards providing workflow capability to that organization (thus it is a vertical segment).  

• Core Capability – A capability is often associated with a slightly lower level of detail than the Reference Architecture. An example of this might be a BPMN design tool for business users to create their own workflow. Within the example Reference Architecture listed above, the design tool is located on one of several servers and provides its own unique interface that may not be generally available to the rest of the users in the presentation layer (for the BPM / workflow tool). Capability definition is used to facilitate requirements development and Use Case modeling. A Capability in this framework approach is roughly equivalent to a complex pattern.

• Complex Pattern – A Complex Pattern simply means that more than one pattern is being employed. Although allocation of scope to patterns is a somewhat subjective exercise, the goal within the paradigm presented here is provide as narrow of a pattern as possible in order to help drives specific decisions regarding solution allocation and configuration standards. The above Capability example represents a complex pattern as there are several distinct elements to the workflow mapping solution (each of which may involve different options to realize). 

• Simple Pattern – A Simple Pattern is the lowest level of architecture or design control; in other words this is where we specify the details for how the solution ought to work. For example, using the ongoing example, we might assign separate Simple Patterns for the Design UI approach for the modeling tool based upon whether it is being delivered to a PC or a mobile device. 

• An important consideration here is the notion that an organization can have more than one methodology; and in fact many organizations now have at least two, a traditional Waterfall approach and an Agile approach of some type. More complex organizations may have any number of methodologies to deal with; for management of Data Centers ITIL could be considered a methodology, for government Acquisition DoD 5000 is used, for data-centric projects many groups create approaches based upon DAMA’s DMBOK (Data Management Body of Knowledge) and so on. The design mapping described and illustrated below could be applied to any / all of those situations. 

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

How to Set up an Enterprise Architecture Practice

What if someone walked into your office and told you; "you're now in charge of Enterprise Architecture," what would you do? Where would you start? Here are some suggestions...

First, you'd need to be cognizant of the mission implied with such a request. There are in fact two missions that might be involved depending on what type of organization you support. Those missions are:

1. Internal Architecture Management - This mission is focused entirely on supporting internal processes, systems and infrastructure. While these solutions may themselves facilitate core client-facing business compatibilities, the architecture group does not directly interact with those clients. This type of EA group or department would of course interact with all other internal organizations and with partners.
2. External Architecture (EA) Consulting - EA Consulting is an entirely customer-facing mission (even though many of the customers you'll have will their own customers). This mission is the one more traditionally associated with the concept of a "Practice." The primary difference between a practice and an internal department is one of flexibility versus absolute subject matter expertise. An EA practice by nature must be able to support any type of organization and thus must be structured for rapid assessment and problem-solving whereas the EA department is more focused on ensuring project success and corporate continuity.

There are some occasions when an EA group may take on both missions, but that's relatively rare (reserved for some of the larger IT consulting companies). Once you understand the primary mission of the EA group you've been tasked to create, then there are five basic steps you'll need to follow in order to get it up and running:

• Step 1 - You'll need to do a thorough assessment of your organization (and its target market). This encompasses quite a lot actually, including - all existing systems, all currently used lifecycle approaches and tools as well as all business processes, goals and the corporate culture/s.

• Step 2 - You'll have to decide what EA means to you and your organization. Rule number 1 about EA - it means different things to different people and no two organizations implement it the same way. In defining what EA means what we're really referring to here is the ability to map EA frameworks, tools or processes to the business culture and environment and then align all of that with corporate expectations. The result is - as we alluded to - always a somewhat unique interpretation of what EA is for that particular organization.

• Step 3 - You'll need to choose, customize or otherwise develop a methodology and align that with the core business objective of your organization. This is one of the hardest parts of setting up an EA group because it usually requires integration with and or rework of existing lifecycle processes.

• Step 4 - You'll need to select what tools you'll be using. On occasion you may actually have the tools you need to start with but that isn't often the case and even when it is those tools are generally underutilized or otherwise lacking in how they're being exploited. Keep in mind that the tool or automation does not in itself make a practice or EA department magically come together - however building an EA group without one is fairly daunting.

• Step 5 - You'll then need to apply and integrate the tools and methodologies with your targeted portfolio of projects and or systems (or clients). This is where the rubber meets the road and where any ROI that might occur should happen. EA that only facilitates strategic planning and isn't fully linked into project architecture is a generally very poor value proposition. EA is ultimately an integration solution but to become that you have to go out and make the necessary connections with all other aspects of the enterprise. 

This of course represents only a very high level overview of what goes into building an EA practice or department - but it does cover some of the most important considerations.

Copyright 2012  - Technovation Talks, Semantech Inc.

Read More

Demystifying Enterprise Architecture - Part 3

Part 3 – Utilizing EA as the Enterprise Interoperability Framework
We have thusfar explored how an EA can be used to help provide and identify a unification framework for the enterprise, how to use it to align all aspects of design but perhaps the most powerful application is as a facilitation mechanism for interoperability. A certain amount of that facilitation is de facto present once the first stages are undertaken. The ability to place all of the architecture information within a context in one’s own enterprise is the first step towards extending capability across multiple enterprises. To follow with our previous analogy with enterprise as organisms, the organisms must coexist to some extent within larger ecosystems. The interrelationships between entities determine the level of cooperation or collaboration that can take place. Those inter-relationships are built upon shared ‘cultural’ or cross cultural understanding.

The entire notion of ‘Services’ within a Service Oriented Architecture is more or less based upon this premise – capability structured through relationships on a ‘need to use’ basis rather than through assumption of need arranged by hierarchy. It is philosophical battle; deterministic logic pitted against the laissez faire availability of flexible pieces of an undefined puzzle. The philosophical view of SOA takes us one step close to expression of architecture as DNA. Within SOA, the term ‘loosely coupled’ points to another important consideration for architecture as interoperability mechanism – the fact that architecture elements or components are more effective when left flexible and in this the flexibility is engendered through abstraction. In the past, using deterministic logic, systems literally hard coded the relationships between data and application logic thereby linking them synergistically in a rather negative way. The interaction and impacts of large, highly controlled inter-relationships made maintenance difficult and eventually impossible across data and application layers. This led to multi-million line chunks of code and highly tangled data structures with little effective way to separate logic back out.

An example of using EA as an Enterprise Interoperability Framework

Our focus on SOA doesn’t mean that you have to adopt SOA per se in order to facilitate interoperability; in many ways SOA as a term or discipline is highly misleading or confusing as it means different things to different people. The principles we’re describing here are not attached to any point in time hype though, when the term SOA goes out of fashion, the following principles will remain.

• Interoperability is multi-directional, many-to-many in nature. Point to point or one to many paradigms have limited value.
• Interoperability depends upon abstraction, the levels or types of abstraction are basically unlimited – anything can be abstracted from anything else.
• Interoperability can be visualized and mapped (but this eventually must become reactionary rather than visionary as the level of complexity increases).
• Non-deterministic interoperability will result in lower complexity and reduced management overhead.
• Interoperability is relativistic – the universe of possible interaction is simply too much to imagine; it represents variability at the quantum level, so why fight it? There will be some basic rules governing environmental behavior, but these rules will be designed to allow for flexibility.  

Conclusion
What we’ve described above represents a somewhat radical departure from how enterprise architecture is currently viewed and practiced. To get from where we are now to this will require some time and thought as well as experimentation. However, the philosophical premises postulated here have the potential if implemented together to drastically transform the entire practice of IT. If anything is certain it is this – our technological progress is outstripping our ability to manage information. This is happening because we are still tied to the deterministic philosophies founded when resources, memory and scope was limited to a tiny sample of the potential virtual universe laying before us. Memory, scope and scale are now opening across a wide aperture – we’re viewing the infinite just beyond the horizon and lack the vocabulary to describe it.

Copyright 2012  - Technovation Talks, Semantech Inc.


7X6KFAEETJPC

Read More

Demystifying Enterprise Architecture - Part 2

Exploiting EA as a Primary Enterprise Unification Mechanism
For many, this is what EA was always supposed to be. When handed the EA tools and methodologies currently recommended by industry, though, this objective seemed somehow to pass out of reach. So how exactly could an EA fulfill this role?  Every enterprise is composed of a series of lifecycles – development lifecycles, integration lifecycles, operational lifecycles and these are all contained within the larger organism of the lifespan of the enterprise itself. The enterprise is alive in a very tangible way, but it is hard for us to visualize how it came to be, how it has grown and how it will continue to thrive. Where is the map, the key to how and why it developed the way it did? All living organisms are built upon a code, one that captures its evolutionary history – we need enterprise DNA.

DNA captures the system of systems as well as all of the constituent components; it captures the rules and road-maps for component and holistic transformation. DNA is universal and wholly interoperable, the code is flexible enough to support infinite variation. DNA is data, it is rules and it can be visualized and mapped. DNA represents the single most successful system control mechanism that we know of in the universe, yet even with our extensive understanding of it we have largely failed to apply the secret to its success. DNA works because it is simple, and because it is simple it can manage infinite complexity without intervention. This is our meta model for enterprise architecture, which is essentially an extension of reality, a virtual organism. 

If we begin with this premise and then determine that we need to apply it to an organization we are already taking a fundamentally different path than most follow. Our perspective for what the EA means, how long it will last, our level of commitment to it, all these change once a decision has been made to capture, maintain and consciously craft the living genetic framework of all aspects of the organization. DNA is not something that goes away once an organism matures – it stays for the entire lifespan across all changes, all transformations and passes knowledge forward to future generations within its genetic heritage. When this is done properly, the organism is oblivious to the mechanism facilitating it. Enterprise architecture is almost always attempted across painful fits and spurts – rarely if ever does it become a permanent part of the larger lifecycles that spawned it. And when the EA efforts are tossed aside, knowledge is lost, opportunities for continuity missed and the roadmap vanishes beneath the shifting sands.

Enterprise Architecture includes both Frameworks and Patterns

Once you take the philosophical leap as to what the true nature of EA ought to encompass a number of other realizations start to become apparent, including:

• Narrowly defined or highly specialized EA frameworks while interesting in their own right are ultimately doomed to fail. They are not flexible enough to encompass an enterprise, a lifecycle or combinations thereof.
• Enterprise Architecture cannot be viewed separately from either the systems or processes it is meant to represent – just as DNA is part of an organism, the architecture is embedded into the organization. An EA project that is undertaken as external snapshot cannot hope to achieve a true understanding of what the organization or project is all about and it will ultimately provide disappointing results.
• The language of architecture must at all times be accessible to all participants in the enterprise who have a vested interested in its health. Once the visualizations, notations, frameworks or terminology become the province of ‘architecture experts,’ the value of the architecture has been lost and the EA will gradually or rapidly whither away.
• Architecture is also a communication medium through which understanding can be conveyed and assimilated. It becomes the basis for all other collaboration, the reference point for where each conversation begins and the parameters of the discussion.

In order to leverage EA as the primary unifying force in your enterprise, you must first discard your previous assumptions of what architecture is and how it is currently practiced and focus upon how to make it relevant to the purpose it was intended for. It is a map, a guide if you will and shouldn’t have to be deciphered to follow. It is also not something to be handed off to others isolated within or outside of your entity, it must be endorsed and embraced from the top. The form which it takes is largely dependent on the needs of the organization, although for an EA to be leveraged for enterprise unification it ought to share certain characteristics, such as:

• The EA must have a clearly defined semantic model, using common, easily identifiable terms and conforming with industry standard terminology where possible.
• The EA must have ‘hooks’ into all of the core processes utilized across the enterprise.
• The EA must have the ability to be subdivided without losing its ‘DNA’ integrity.
• The EA must be universally available to anyone who wishes to either reference it or work with it; this implies that it must be updateable using a flexible ‘social publishing’ paradigm and be entirely web-based.
• The EA must encompass the enterprise lifespan allowing for unlimited lifecycles within – this is the only way to build true organizational traceability. 
• EA management must support some level of automation – for EA-based unification to function properly, it can’t be a continuous manual process.

In many ways, the philosophical commitment is the most important step in any EA effort; it is also the first one which must be addressed. After an agreement has been reached as to how EA should be used then there needs to be an examination of its practical implementation. The first and most obvious practical application of EA is as the design framework for your enterprise.

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

Data Driven Cyber Security

Data without meaning has no value. Data that is interpreted too late to respond to a situation has only forensic value. For too many years, computer network security and information assurance practices have focused solely on forensic capabilities. Semantics is the science of applying meaning – to symbols, to language, to data and to events. If meaning can be mastered, it can then be portrayed effectively in analytical displays. The combination of Semantic definition of the Cyber landscape with innovative analytic engines provides us for the first time with the ability to link multiple communities together in a proactive unified Cyber response, in real-time.

Data is the glue that binds together our ability to perceive and mitigate Cyber Threats.

A Comprehensive Cyber Security Methodology requires Cyber Semantics & Analytic solution components - those components include the following core capabilities:

• (Attack) Pattern Definition – The beginning of the Semantic foundation is the collection and / or predictive definition and provision (or definition) of attack patterns. 

• Dynamic Threat Correlation – Attack elements are correlated against patterns in real-time to help determine both the threat level as well as potential actions. This becomes a pattern matching exercise; and more importantly, one that occurs across multiple partner organizations. 

• Dynamic Incident / Event Collection – Provides the ability to collect and synthesize attack data as attacks are occurring (for use both in immediate remediation as well as later analysis and reconfiguration)

• Cyber COP – COP stands for ‘Common Operating Picture.’ The ability to build this atop a Semantic foundation allows for dynamic and community views as well as comprehensive activity aggregation.

• Cyber Enterprise Architecture (EA) – Enterprise Architecture is the blueprint for infrastructure environments as well as the software and analytics which are housed in those infrastructures. Our Cyber EA approach is built using the same focus on Semantics – allowing for coordination from the ground up.

• Mission Intelligence or Reporting / Cyber Health Dashboards – One thing that has become abundantly clear over the past decade is that Cyber Security is a time sensitive activity and that traditional security analytics are painfully slow.  In order to get ahead of the curve – there must be automated alerts and warnings built into our Cyber oversight mechanisms. This Cyber Health Dashboard can exist within or separate from a Common Operating Picture. The Cyber Health Dashboard allows individual security managers to catch activity real-time and then coordinate within their larger communities through collaboration to reduce the impact of the attacks. 

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

Capability-Based Enterprise Architecture

Capability and performance; one logically precedes the other, if either is missing they both become meaningless. There has been a tremendous emphasis in recent years on the ability to measure and track performance – this has led to many positive improvements in the approaches to portfolio management, governance and accountability. However, when these efforts are discussed it feels as though we’re only getting it half right; if we artificially separate the two most important aspects of any IT project why should we be surprised if the outcomes still aren’t predictable ? IT projects as compared with other business endeavors tend to suffer from a much higher ratio of unpredictability and the risk of failure tends to increase in proportion to the relative complexity of the project. While there is no silver bullet to change this situation, improved outcomes are possible if we re-examine some of the core assumptions we tend to start with on any given IT project. There is also a set of actionable techniques to make this happen, something that could be referred to as Capability-Based Architecture. Why the emphasis on capability, because it is our logical starting point…

Enterprise Architecture (EA) is a very powerful tool, one that has yet to realize its full potential. Too often it has been applied to parts of the overall IT oversight process but seldom if ever to all of it. That is precisely what needs to happen; enterprise architecture can and should become the central organizing mechanism for management of IT capability, and not simply be employed as a mechanism to facilitate governance or design. What has been missing in this equation is some sort of methodological context that would allow for use of EA as a medium to both visualize all the associated concepts and track the pertinent data. The focus on capability management provides a suitable framework and blends very well into efforts already in place to manage performance. Let’s take a closer a look at several typical IT project assumptions and how employing a capability based architecture methodology could change our perspective.

A DODAF view of how Capabilities can be represented by EA...

 Assumption 1 – The RFP = Requirements

While many projects are different in that some are overwhelmingly dedicated to developing new (unfielded) capabilities and others are dedicated to the provision of services for existing capabilities, ultimately every IT project starts with a capability expectation. The problem with an RFP being requirements focused is that often as requirements change the core capabilities associated with them change or become distorted – this is the dreaded ‘expectation disconnect’ that tends to wipe out many large-scale projects. Each and every RFP that goes out should contain a capability expectation description and this should map directly into a capability contract. The main idea here is that specific requirements will roll up to the capabilities but it is understood from the beginning that under no circumstances will the capability expectation change, requirements can remain flexible as long as they do not exceed or underachieve the agreed upon expectations.

To combat this assumption, each project can model as the very first step in an expanded EA process the set of solution capabilities they are seeking to achieve and then drill down to “requirements” level objects. At the early stages these requirements objects would likely be equivalent to business or functional requirements. Any capability has a matching set of functions which can be described using requirements objects, this can be visualized as well as verbalized to help ensure understanding of project scope and expectations. Depending on the extent of integration an organization has achieved with its EA process, all capability sets can be derived from business goals & objectives and mapped to projects and project elements. The visual roadmap can scale up through the enterprise or down to the lowest level of development. 

Assumption 2 – It is difficult to determine performance before a solution has been fielded

If we follow the premise that all aspects of a project branch out from the initial capability expectations, then it stands to reason that capability expectations can drive definition of performance expectations before project launch. The key of course is to explicitly link them in the RFP or statement of work. The reason most people find metrics definition and performance work statements difficult to build is that they lack the solid foundation that a capability map and contract would provide them.

This assumption can be addressed through the capability based EA by creating Key Performance Indicators, Measure of Effectiveness or similar objects mapped to each capability. Each set of requirements under a particular capability object hierarchy would then have starting point for more specific measures. This can later be extended as the project progresses as long as it is clearly understood which measures are contractually binding are which aren’t (i.e. additional tracking of project or capability health may lead to metrics not originally considered but these would not be tied to service level penalties if not met). Of course, this highlights the importance of determining most of this conceptual framework up front, whatever is not defined and made legally binding becomes a risk.  

Assumption 3 – The Project and Capability are Separate

Many if not most IT decision makers tend to view the anticipated solution or delivery of capability as largely separate from the project which produced it. This seems a logical enough usually with capability only emerging towards the end of a project in milestones sometimes referred to as Initial Operating Capability (IOC) and Full Operational Capability (FOC). This leads to several problems starting with the inability to create a linkage from the larger set of enterprise goals and objectives to the project which is in reality solely defined by a subset of capabilities mapped to related enterprise goals. The other major problem that arises is that the project management itself loses its capability based context when schedules and work efforts are viewed out of the context that makes them relevant. The project is the facilitating medium for the evolution or emergence of specific enterprise capabilities, as such everything that occurs during the project itself necessarily impacts the outcome of those capabilities.

This basic premise has a number of common sense implications:

·       If the project isolates itself from the leadership who determined the initial linkage of goals to objectives to capabilities it is likely that there may be gaps in interpretation.

·       If the project isolates itself from the intended user community of the capabilities, they will have a difficult time mapping those capabilities to lower level design requirements.

·       The project thus represents both a lifecycle and communications continuum. The capability lifecycle begins at conceptual definition and continues through capability retirement – the development / deployment project becomes the primary means of linking all of the lifecycle elements and communities together.

·       All aspects of any IT project can be visualized or modeled using the same framework applied to the solution architecture (preferably within a larger enterprise context), and in fact this integration of project and solution is perhaps the most effective way to reduce uncertainty in complex IT projects. Existing technologies can provide the ability to merge data from various tools such as MS project or EA modeling tools allowing for comprehensive tracking and analysis of capability evolution.    

Assumption 4 – New Capability = New System

Too often in IT simple conceptual roadblocks tend to cause larger practical problems, some of which become so complex that it becomes difficult to untangle what went wrong. One of the conceptual roadblocks that is particularly dangerous is the notion that any new capability requires the development, procurement or major modification of a system. This problem translates even into several of the popular paradigms use for EA modeling. If decision makers followed a capability based approach this roadblock could be bypassed in many cases. The capability does not distinguish between the relative options which may allow for its actualization. In other words, new capabilities can be derived from existing technologies or systems which simply need to be re-purposed. The extent or scope of the work involved in repurposing can vary widely, however it is almost in every case smaller than the scope of work needed to generate a new capability from ground zero as a new system (be that as software or through integration of various system elements).

There are a number of examples of how this is emerging right now with web technologies:

• Podcasting leverages the RSS standard and available media formats to create a new audio delivery capability.
• Blogging is a variation of several web publishing technologies.
• Wikis & Commons are variations on previous collaboration and content management web technologies.

How does one build in the flexibility to determine whether a capability should manifest itself as a new system or whether it can leverage existing organizational assets & technology ? This can all be modeled as part of the capability based architecture approach. Each capability can display its own set of alternatives (objects) which in turn can display hierarchies of detail per the needs of the organization covering aspects such as risk, cost, complexity and assets available for reuse. In essence an Analysis of Alternatives (AoA) should occur for every capability-based process. While most view an AoA as an obscure engineering exercise it is in reality perhaps the single most important yet underutilized project management technique available to decision makers.

What has been described here doesn’t in most cases require significant new investments in technology or expertise. Capability based architecture and management is a conceptual framework for mitigating complexity – it accomplishes this by allowing any sized project to keep a clear focus on the core elements which remain constant throughout a lifecycle that extends beyond the project itself. Once this approach is adopted, a ‘capability roadmap’ can emerge, linking all enterprise projects and all stakeholders.     

Copyright 2012, Semantech Inc. All rights Reserved

Read More