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

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

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

Problem Solving & Enterprise Architecture

You may be asking yourself – what do Enterprise Architecture and Problem-Solving have to do with one another? At first glance it may seem logical that there is some sort of indirect relationship between the two, but the details of that relationship aren’t entirely clear. We’ll begin to answer this question by introducing a number of fundamental assumptions associated with Enterprise Architecture (EA):

• EA is generally focused on one of two things (or both); either the introduction of new capability or the enhancement of existing capability.
• If achieving either of those objectives were simple, the concept and practice of EA never would have been contemplated and introduced.
• The enterprise is dynamic, the technology that drives it is dynamic and neither of those preconditions will ever change.
• The first three assumptions point to a complex, evolutionary environment. One can either react to change or attempt to be proactive. Usually we end up doing a combination of the two but when we become entirely reactive, management of the enterprise suffers. EA is meant to be proactive and is meant to facilitate change management.

So how does one manage change? Can change be predicted, can it be harnessed or can it be ignored? What does change management really mean?

Lot’s of questions. Here are some of the answers:

1. One manages change by defining it first, then anticipating aspects of it in advance.
2. Yes, change can be predicted – up to a point – but only if the context (both internal and external) is well understood / partially defined in advance.
3. Change cannot be ignored.
4. Change management is merely the application of an overall lifecycle dedicated to solving one problem at a time (within a defined list of problems and a defined problem solving methodology).

Key Concept: “Problem Semantics”
Reality – all reality – is defined, perceived and validated through a semantic layer. This takes many forms in everyday life. In IT, we have an exceptionally rich toolkit dedicated to managing semantics or meaning – this includes everything from programming languages to canonical models to technical standards and much more. For our discussion, Problem Semantics refers to the ability to define problem sets or problem spaces.

This is the high level exploration of the who, the what and the how of a specific issue – whether it be the introduction of mobile devices to a sales force or the transition of legacy code off a mainframe system or how to control space probes on Mars. It can be more basic or more complicated – but this is where the vocabulary of problem solving is born. The problem semantics eventually are blended into the larger semantic foundation of the enterprise – often they are defined by industry and more or less ‘imported’ into use by industry adopters. And of course, often times Problem Semantics are already well known.

We have proposed that EA is closely related to the concept of Change Management and that Change Management is associated with Problem Solving on a case by case basis within the context of a larger lifecycle. Making these associations and distinctions is important because many people believe that enterprise architects are merely exercising one part or another of the solution lifecycle. The reason this makes a difference is continuity. Many of us have experienced first-hand the enterprise where the same problems are solved over and over again by different groups – where past knowledge is discarded only to be earned again a great cost. We should be able to solve one problem at a time and not have to solve it again. Even better is the ability to solve small chunks of a large problem across multiple iterations of effort and achieve otherwise unreachable goals. These are the benefits that enterprise architecture brings to the table and why problem solving with EA is both quantitatively and qualitatively superior to scenarios without it.

Any type of Problem can be managed use the same core methodology...

 Key Concept – The Problem Space
A problem space uses Problem Semantics and EA tools to describe problems – there are often multiple related problems within a shared problem space. This does not map well to the UML concept of a Domain Model because there are generally a number of problem spaces which must be addressed for any given domain. There is a rough correlation between Use Cases or User Stories and Problem Spaces, but as yet UML doesn’t really support this high level modeling concept. Essentially, ‘problems’ are the core challenges being faced and they coexist in relationships within topically related spaces. As these Problem Spaces are better understood we begin to use that context to build more direct solution focused artifacts.

A complex Healthcare Problem Space Example
An example problem space might be something like this: a company is rolling out a new online product never before attempted (by them or anyone else) – up front it is difficult to determine:

• What customer reaction will be.
• What type of performance may be involved with the system and user experience (because initial predictions of user load and behavior have no baseline to work against).
• Whether the business model will be viable over the long term.
• Whether the current support and failover model is sufficient.

These characteristics cross a number of technical or business boundaries but they are related in the context of “new online product deployment.” The standard response to most of these questions is – “we’ll have to wait and see whether our best guesses pan out.” However, that wait might result in a complete failure. There must be a better, more methodical way of reducing risks associated with deploying evolutionary capability. Much but not all of the risk can be reduced if we have the ability predict key issues before they occur. And this leads to our next

Key Concept - Problems, like Architecture are Pattern-Based
So what does that mean, pattern-based? It means that is highly unlikely that the issues you will face in one enterprise are radically different or wholly unique from every other enterprise. This is equally valid going backwards or forwards through time. There is always a first time someone runs across a problem but most times you will not be the first one to face it. This leaves open the possibility that through the use of enterprise architecture a much wider range of problem solving can occur and that as more knowledge is captured the problem solving itself becomes less complicated and more accurate.

Another key aspect of viewing Enterprise Architecture as problem solving is the nature of problem solving itself. What we mean by this is the fact that the most effective approach to solving problems is generally by asking the right questions. The ability to string together a continuous dialog on a single topic is known as dialectic. This is what EA’s must do all the time – it is why communication is such an important part of any architect’s role or skill set. EA’s are often the ones who are asked to facilitate a larger dialectic process for an organization.

Think of it this way perhaps – one of the biggest trends in IT today is Agile Development – why is Agile so important? It’s important because it assumes as its core tenet that the people who ought to be talking together aren’t and it changes the lifecycle process to make sure they do. Now where Agile differs from EA is that Agile achieves the improved communication by shrinking the topics down to tiny – byte sized chunks. EA’s on the other hand must deal with the macro-level problems while understanding how they will be tackled on the micro level and we must be able to ensure that all low level and high level efforts fit together in the end.

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

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 

Read More

What does an Enterprise Architect Do?

The first thing most people think when they hear the title “Enterprise Architect” is that this person does some sort or modeling or design activity. Architecture is and always has been a visual medium and in some sense that initial metaphor which connects IT architecture and brick and mortar architects remains valid. Most EA’s need to know something about design – whether it be in the context of a specific design tool or paradigm or just the ability to visually depict complex topics in an intuitive manner. What is important to keep in mind though is that there is no one “right way” to model or design and that these visualization activities represent only a portion of what the enterprise architect does within a typical engagement or project.

There are many who might disagree with the “right way” comment – some of those people may feel that a particular EA framework or perhaps UML is the one preferred way that work should be prepared. To some extent, UML has achieved a universal status of sorts and can be used within most other EA frameworks; however there are some things UML is still not good at representing. For example, high level Domain models and Use Case diagrams convey relatively little information yet there can be richer depictions of operational concepts at a high level (what is generally described as an OV-1 in DoDAF or ModAF or perhaps a BRM in FEAF). There will always be room for flexibility in the way that information can be presented visually and then the question becomes how important is it to capture aspects of the information being presented in a data driven tool. The secondary question might be whether a non-standard visualization is meant for one or more audiences. Often times what is useful for business stakeholders may not be helpful to developers who need more specific design notation to support application development.

Most EA artifacts begin w/ taxonomies - this one was used to develop a DoDAF TV-1

Now we come to one of the truly vexing aspects of working as an Enterprise Architect – each organization is going to view things slightly differently. There will be different opinions about role, process and deliverables from one engagement to the next. This may even be the case within a single organization but is certainly the case when crossing from one organization to another. What this imposes on the EA is the need to understand or be fluent in multiple different approaches and to be capable of developing new ones as needed. This was one of the reasons we made a point within the EA Manifesto of stating that the tools or products don’t drive Architecture, they merely support it. One of the main responsibilities associated with Enterprise Architecture is the ability to tailor tools to unique organizational expectations and still allow both to function properly.

Yet all this is still only part of a bigger picture. The EA is not merely expected to be able to model or design in different tools using different modeling paradigms – we’re also expected to:

• Understand all or most of the technologies involved (in a project, in a domain or across the whole enterprise).
• Be able to help develop, assess or implement strategic objectives or initiatives. These sometimes extend beyond pure technology-based capabilities.
• Be able to estimate scope, cost or schedule for initiatives or parts thereof.
• Be able to support functional and technical requirements gathering and validation.
• Be able guide product evaluation processes.
• Be able to evaluate new technologies in a less formal sense and project future impacts.

And the list goes on. The EA is not an executive position although on occasion EAs are also asked to provide various types of leadership, such as:

1. Solution Evangelism
2. Industry Thought Leadership (1 and 2 often work in tandem)
3. Oversight of specific projects
4. Tech Oversight of the enterprise

As you can see, it’s difficult with all of these types of expectations for an enterprise architect to become specialized in any one area – in fact if he or she did it would likely reduce their effectiveness in the role quite a bit. So, in answer to the title question, what an EA does is whatever the customer asks them to do at any one given time – keeping in mind all of the other expectations that relate to the immediate need and the role. EA is often viewed as entirely strategic, but the reality is that it is a pragmatic mix of strategic goals and tactical needs. This balance can be met if one side doesn’t give way entirely to the other. For example an EA that never becomes involved in the day to day operational issues of an organization may find themselves hopelessly out of touch after some time and the relative value of their strategic contributions would likely decrease proportionately.

Copyright 2012, Semantech Inc. All rights Reserved

Read More

The Enterprise Architecture Manifesto

This post was originally published on another blog - but we thought it would make a nice segue into our Technovation Talk # - Understanding IT Architecture...

Enterprise Architecture (EA) is a relatively new and perhaps not fully mature IT discipline. The practice and philosophical grounding for EA varies widely and even though it has become an accepted, important part of the IT industry, there are still many who cannot agree on what it really represents. Others contend that in its current state of practice or understanding, it is ill-suited to accomplish the task assigned to it by most organizations which currently exploit EA in some fashion.

One reason that both consensus and efficacy remain elusive for EA is that there has not yet been an industry-wide statement of goals or expectations for its practice. The purpose of this blog is to advance a proposed set of expectations for EA that will support current practice as well as it evolutionary trajectory. This statement of expectations is the EA Manifesto. Our first post will introduce the initial draft of the manifesto and all follow-up posts will be dedicated to providing real world examples of the key points from the manifesto as to how the next generation of EA can be achieved. We may also incrementally enhance the manifesto as time progresses.

EA Manifesto 1.0: Tenets:

1. EA is not and cannot be entirely product-centric; it can however be product supported. The nature of which products may support EA practice will remain dynamic over time.

2. EA can and should be Agile in nature. This does not necessarily imply strict adherence to all tenets of current Agile development methodology but does concur with a number of its key principles, including:

• Timeboxed, iterative development
• Evolutionary requirements
• Collaborative feedback
• Acknowledgement of a dynamic, evolving landscape.

3. EA must always be measured by its relevance to the client or organization it serves.

4. EA is first and foremost a problem solving mechanism.

5. EA is proactive and creative by nature. While it requires analysis it is not solely analytic. EA is solution architecture extended or multiplied across diverse systems and environments.

6. EA is not merely limited to high level, enterprise concerns. It can and does involve integration of solution elements both vertically and horizontally.

7. EA is controlled rather than ad hoc integration.

8. EA is the primary visioning tool and main communication platform for advocating and implementing enterprise initiatives.

9. EA as opposed to many other forms of specialized architecture is general in nature. It must be generalized in order to support the following key capabilities:

• The ability to span organizational and technical silos
• The ability to adapt rapidly to change
• The ability to predict, design and understand the nature of highly complex integrated systems.

10. EA is primarily dedicated to managing complexity and facilitating (continuous) transformation.

11. EA must necessarily encompass both the business and technical domains of each enterprise it serves. This then allows EA to perform perhaps its most valuable function – mission integration.

Copyright 2012, Semantech Inc. All rights Reserved 

Read More