Reinventing Enterprise Architecture

I've seen articles recently proclaiming that Enterprise Architecture (EA) is dead. Of course, I've seen the same proclamations for SOA, for COBOL and any number of other technologies or IT practices over the years. These premature announcements all have one thing in common - they equate the value of a technology (or technology practice) with its current position in the hype cycle rather than its actual utility. There is another thing these death notices fail to grasp - technologies aren't static and they aren't always replaced by something new. But before we dive further into this topic, perhaps it is worthwhile to revisit what the current expectations for Enterprise Architecture.

Sadly, Mark Twain is really dead now, but EA isn't...

EA, as it is currently defined…

The set of high-level design activities necessary to support IT portfolio planning and/or specific IT Transformation initiatives. While EA is typically considered primarily a business-focused activity, it is also often concerned with high-level design of data, application or security solutions. EA is typically distinguished from other types of architecture by the scope or scale of the associated problem-space.

Now, this definition doesn't capture any of the core issues associated with the typical exploitation of EA in most enterprises and the reasons why some people have determined it is no longer relevant. And, like most other aspects of technology, there are legitimate issues associated with EA and a history of many Enterprise Architecture efforts not meeting expectations. Some of the problems that have been associated with EA over the years include:

• A lack of understanding as to what value it provides
• A too narrow focus on feeding (building out) an EA repository
• Lack of connection to the actual IT solution architectures

Sometimes, when we hear the word "Reinvention" we get the impression that whatever needs to be reinvented is somehow broken; that's usually not the case and it is definitely not the case with EA. What Reinvention does imply however is that there is always a need to evolve and improve - that is how any capability, technology or set of skills remain relevant over the long-term. Reinvention allows us to enhance what works, replace what doesn't and redirect all of it in more meaningful ways. That's exactly what I'm proposing for Enterprise Architecture.

So, how does one go about reinventing a major IT field of practice? 

It starts at the beginning - the expectations for that practice. These new expectations must take into account both the lessons learned (the current criticisms) as well as the trajectory of future need. The expectations fall into three categories:

1. Greater Flexibility
2. Greater Agility
3. More Relevance

EA must become more Flexible
Some of the severest criticism of enterprise architecture comes from those who have seen EA become a means unto its own end. In other words, the practice of EA has sometimes been overly focused with the management tools used to implement it. These tools are powerful and typically include EA repositories, technology catalogs and various analytics. These tools are also typically built atop a foundation known as an Enterprise Architecture Framework. These frameworks, which I will talk about in more depth in some future posts, include TOGAF (general), DODAF (military), FEAF (federal) and Zachman (general). The Zachman and TOGAF frameworks are typically better suited for commercial environments while the government ones tend be mandated as part of the larger IT portfolio processes of the agencies involved. 

The key thing to keep in mind with Frameworks is that they merely represent meta-models of what the types of things a typical organization ought to be concerned with. In this respect they are much like ITIL (which is essentially a taxonomy of data center processes) or like standard industry EDW data models (for energy, healthcare etc.). The Framework/model becomes the schema for the EA Repository and then the tool helps architects to build visualizations using data placed into that repository. The problem is that sometimes this process of building out the repository and the enterprise view of what's happening becomes too inwardly focused and too rigid. The flexibility required moving forward is this:

1. The tools are there to help the larger process of assessing the enterprise and supporting planning. That means that the tools must also serve the process and not the other way around.
2. The meta-models are not the end-all, be-all of what can be done with enterprise architecture. Like EA itself, all of these meta-models are evolving and there will often be important aspects of what's happening in the enterprise that aren't properly covered by the framework. EA is more than any given framework and can exist beyond them or even without them if needbe.
3. The work that an Enterprise Architect does is part of a larger continuum. We'll talk about that a little more in a minute, but the key thing to keep in mind here is that the Architect and the organization need to understand where and how the work fits in - and be willing to adjust as necessary (rather than staying on the same rigid course regardless of what is discovered).

Agile EA is possible...

EA must become more Agile
This is also a popular criticism of Enterprise Architecture; that it is often a rather lethargic and abstract exercise. Well, sometimes it is true, but that of course only happens when the activity is not made Flexible (see above) or more Relevant (see below). But what does Agile really mean in the context of Architecture? Many people might think that the two concepts represent a sort of cognitive dissonance. That's not really true though. Enterprise Architecture, like any complex enterprise level activity can be made more Agile by simply changing the expectations associated with it; for example:

• That analysis or assessment activities be time-boxed and aligned with specific goals or initiatives.
• That building EA deliverables or documents serve a specific purpose, such as Portfolio review or creation of Reference Architecture guidelines.
• That EA is not a giant one-off effort, but rather a more or less permanent and iterative process, that allows for continuous innovation as an organization.

Making it Real (or at least Relevant)
This is perhaps the most important change that needs to occur, but it also happens to the be the least recognized by most groups who are actually having issues with EA. This is borne from the problems associated with lack of flexibility - namely the stove-piping off of EA from the rest of what the enterprise is doing. I've been there, seen that - an EA group producing something that is totally ignored by other groups charged with making strategy real. There is one sure way to cure this problem and that is to connect EA to the rest of the IT lifecycle. The first step in doing that is understanding where EA fits in the larger spectrum of IT Architecture and then building the necessary links between all design and governance process for IT capability. 

EA when viewed by itself, represents the strategic or business focus of the larger IT Architecture mission spectrum. It is where enterprise options are assessed and where organizational strategy becomes an actionable plan for achieving organization-wide capability. It is also the starting place for all design. This unique, combined role places it squarely in between business and technical interests and their respective stakeholder groups. The future of EA is with this role empowered to broker issues between the wants and realities of the typical enterprise. EA is not analysis for its own sake - it is an ongoing and collaborative process for ensuring that Digital Innovation or evolution occurs according to plan.

copyright 2014, Stephen Lahanas

Read More

Why Most Organizations need a Data Strategy

One of the most important tasks that a Data Architect is often asked to help with is the creation of an Enterprise Data Strategy. But why is Data Strategy so important and what exactly does it consist of, and lastly why is this a task that a Data Architect should be leading or supporting?

So, what is a Data Strategy? Let's review what it isn't first…

• A Data Strategy is not a list of generic principles or obvious statements (such as "Data is an Enterprise Asset")
• A Data Strategy is not merely a laundry list of technology trends that might somehow influence the organization in coming years
• A Data Strategy is not a vague list of objectives without a clear guiding vision or path for actualization.
• A Data Strategy is not merely the top level vision either, it can expand into critical data domains such as Business Intelligence and eventually represent a family of strategies.

Now we will attempt to define what an Enterprise Data Strategy really is:

Enterprise Data Strategy is the comprehensive vision and actionable foundation for an organization's ability to harness data-related or data-dependent capability. It also represents the umbrella for all derived domain-specific strategies, such as Master Data Management, Business Intelligence, Big Data and so forth.

The Enterprise Data Strategy is:

• Actionable
• Relevant (e.g. contextual to the organization, not generic)
• Evolutionary (e.g. it is expected to change on a regular basis)
• Connected / Integrated - with everything that comes after it or from it

This definition helps to understand what Data Strategy is; so now we need to understand why most organizations need one. Here are a few of the reasons why…

1. Without a centralized vision and foundation, different parts of the enterprise will view data-related capabilities differently. This inevitably leads to duplication of both data and data systems across the organization and thus makes it quite difficult to determine the 'truth' of one's data and will also drive up costs.
2. The Data Strategy provides the basis for all enterprise planning efforts connected to data-related capability.
3. The Data Strategy is the tool that allows for unification of Business and IT expectations for all enterprise data-related capabilities. The more detailed and comprehensive it is, the better the chance that both sides will fully understand each other.
4. There is no better place to define the metrics or service level expectations that should apply across the enterprise.
5. This is the best place to explain thoroughly how management of enterprise data can be leveraged to support organizational mission objectives or processes.

A Typical Enterprise Data Strategy includes the following components:

• A definition of what types of data or information needs to managed from an enterprise perspective (and yes this ought to be fairly specific).
• A determination in regards to roles (organizational) in terms of who owns what data or data systems.
• A mission statement in relation to exploitation of data assets. So, we've taken for granted here that these are enterprise assets - what's important is understanding how they ought to be used.
• Initial or top level expectations for enterprise-wide service level metrics (for data systems and data quality).
• Introductory versions of all domain-level or specific sub-strategies, such as; Information/Data Governance, EDW, MDM, Content Management, Big Data etc.
• Top level planning decisions or expectations for making those designs.
• Identification of key enterprise challenges and anticipated design decisions.

Now we're ready to address why Data Architects are typically involved in creating and executing Enterprise Data Strategy. Data Architects are specialists within the larger field of IT Architecture, while some have wider architecture experience - others do nothing but work with data and data systems. Data Architects make good candidates for helping to craft Enterprise Data Strategy because they are typically charged with defining all existing and future data related systems capability. Architects often also have a good deal of experience working directly with business stakeholders and thus help to ensure both business and IT perspectives are taken into consideration while crafting the Data Strategy.

There are in fact few other roles qualified to lead this type of an effort. While CTO, CIO or CDO’s (Chief Data Officer) might quality to lead such a task, often times they are stretched too thin to focus on building the comprehensive Strategies necessary to make a real difference for the organization. The Data Architect can typically dedicate their full attention to this task and have the full support of all necessary resources (including the CXO level personnel) to ensure that the necessary analysis, negotiation and planning goes into the Data Strategy so it can be relevant and ultimately successfully.

copyright 2014, Stephen Lahanas

Read More

Creating Agile IT Transformation - part 1

IT Transformation has been a buzzword for more than a decade now, but what does it really mean? The first time I heard it used regularly was in relation to specific Department of Defense (DoD) technology initiatives from the early 2000's. I had the opportunity to work on several of those projects and as the years progressed the concept of IT Transformation evolved quite a bit – becoming much more flexible and yes – even somewhat Agile in nature.

At first IT Transformation was viewed from a more comprehensive perspective, sort of an organizational make-over if you will. This initial view involved Transformation at multiple levels and from multiple perspectives. This often included consolidation of organizational functions as well as IT systems and hosting capabilities – all at once. In some cases, IT Transformation was becoming almost synonymous with Enterprise Resource Planning (ERP) initiatives; in fact some people still view it that way.

A holistic perspective of IT Transformation

The problem with the comprehensive view of IT Transformation though is its scope. As hard as it is to even get a project like that off the ground (funding, stakeholder buy-in etc.) successfully executing something that large is even more challenging – sort of the ultimate “Big Bang” approach. Despite that, Transformations are still hard to avoid – organizations that don’t adjust to changing realities and emerging technologies can rapidly become ineffective or redundant.

So, how does one approach Transformation in a way that can actually succeed? First we need to redefine it:

IT Transformation

“The set of activities required for an organization or group of related organizations to successfully adopt emerging capabilities and practice. This emerging technology or practice could be focused on one major capability or may involve multiple technologies and processes associated with a specific initiative.”

This definition allows us to view Transformation differently. Rather than the entire organization changing all at once we’re focusing now on areas of specific significant change.  This Transformation based on significant enterprise change can be further decomposed into segments similar to the previous view of holistic Transformation (the business portion, the data portion, the solution portion etc.).

You might be asking yourself how this new view of Transformation differs from any other type of major IT initiative or project. The primary difference is that while today’s more Agile Transformation can be highly targeted it still exhibits these differentiating characteristics from typical IT projects:

1.  It is designed to fit into a larger set of Transformation goals (e.g. it comes pre-integrated, enterprise-aligned from day 1)
2.  It typically involves the combination of several distinct technologies and processes – moreso than other IT projects (because it is already enterprise or strategic-facing in nature)
3. It typically is more mission-focused than many other IT projects. In other words, it has been selected to tackle a critical business issue, not just a technical concern.

Solution providers that support this new type of Transformation are somewhat more flexible in their perspectives on how to tackle complex Transformations than some of the more well-established consulting firms may be. While an ERP transformation may easily cost several hundred million dollars and still not succeed, Agile Transformation approaches look for smaller chunks of capability with higher ROI and success rates.  We will highlight the primary Use Cases and several case studies for Agile Transformation in the near future.




copyright 2014, Stephen Lahanas

Read More

Making the Case for IT Architecture

There are still quite a few misconceptions in regards to IT Architecture. For many, hearing the term "Architecture" in relation to any IT topic seems to imply Enterprise Architecture (EA). To others, the notion of formal design processes represents the anti-thesis of Agile or responsive problem-solving. These misconceptions are unfortunate because there has never been more architecture connected to IT in actual practice and there has never been so much need for it.

So, let's start at the top - IT Architecture is a continuum and an umbrella for every design process in the enterprise. IT Architecture is the foundation for understanding every enterprise capability as well as being the starting point for all planning and governance. The reason it serves all these roles is because it provides the necessary insight for guiding all of those processes. Without that insight, making decisions and governing IT management or evolution becomes more or less like guesswork.

Why should this be so? Well, it has a lot to do with the disruptive and dynamic nature of Information Technology; it is not all uncommon for large organizations to have incomplete information in regards to their own systems, costs and data. Often times there are redundant, distributed islands of IT that cross business units or may even involve the separation of capability across IT & business communities. Gaining a complete picture of what's going in many organizations is quite a challenge - but is absolutely necessary in order to unify systems operation and to move forward in a coordinated fashion to exploit new opportunities and technologies.

So, let's go back and address those two very common misunderstandings again…

1 - IT Architecture and EA are the same thing (and EA is useless) - now I've paraphrased some of the criticism I've heard over the years about EA, but of course there is a legitimate question there. Is there any real value to EA? First off, EA and IT Architecture are not the same. EA is a top level architecture process and represents perhaps 20% of the total architecture that occurs in the typical enterprise. EA is integrated with IT Strategy and portfolio planning and governance.

Does EA have value? Yes, it does. It represents that portion of IT architecture that helps allow business stakeholders understand their IT capability landscape. It is high level enough to function as a communications tool, a governance framework and a project estimation bench-marking tool. EA is also, when done properly, the bridge to all other solution architecture.

2 - Does Architecture inhibit Agility? This is a thorny question and a complex topic, but I will try to address it briefly. At first blush, it might appear that any formalized design process might not fit within the context of the Agile Manifesto. But there are some important considerations worth noting that tend to contradict that initial assumption:

• Agile, as a methodology, has never been effectively transferred from a system or application scope to an enterprise scope except through the adoption of more iterative, time-boxed approaches to lifecycle management. There is a good reason for this - purist Agile approaches are focused on deriving requirements through experimentation rather than up front design.
• When you move from the application development scope to the enterprise integration domain things change - a lot. The problem at this level is no longer invention, but reconciliation and complexity management. In this context, the discovery associated with design relates to existing capability and introduction of well-defined new technologies. Here, IT Architecture provides the reference point for establishing and maintaining control over what otherwise might become a chaotic environment.
• Agile is all about making the application work by any means necessary - operations is all about making the enterprise work as a whole in the most efficient manner possible.
• And even within Agile, there is a design process and that process is merely one specifically-tailored component of a larger family of IT Architecture practice.

Perceptions are often hard to change and IT Architecture is a large, emerging and complicated field of practice. After working as an architect for 16 years, I can honestly say I've never seen more organizations doing architecture work. More often than not that architecture has become an important part of their overall IT management strategy. Yet, the continued misconceptions tend to hold back the true potential of IT Architecture. Too often, people view it from the perspective of one of the many sub-disciplines (such as Agile design, etc.) rather than seeing it as a holistic enterprise resource. I think that as the realization of its true scope becomes clearer IT Architecture will become even more important in the years to come.

copyright 2014, Stephen Lahanas

Read More

The Top 10 Mistakes in Data Architecture - part 1

The IT Architecture Journal is meant to help both practitioners of IT Architecture as well as those who might hire architects. It is vital that both of these stakeholder group understand not only the core principles behind the practice of Architecture but also where and when Architecture can go wrong. Today, we're going to talk about some of the more common problems or mistakes that arise in the practice of Data Architecture. While there are no concrete rules or really even standard practices in relation to some of the following considerations; we have attempted to clarify where standard practice is already present or perhaps just emerging.

Architecture can help solve puzzles, but should never produce its own

Mistake 1 - Lack of Context
A great deal of Data Architecture being practiced today is totally generic in nature. This is not just a question as to whether the effort may be high-level or not, even higher-level analysis and design can be targeted or contextual in nature. Part of the problem here is the desire by many organizations to standardize best practice based upon industry-defined expectations. This tends to happen most often in relation to the DMBOK (Data Management Book of Knowledge).

Now, there's nothing wrong with either the DMBOK or the desire to standardize approaches to data management or architecture based upon industry lessons learned. What is problematic however is taking much of that information at face value without the realization that the information was deliberately made generic in order to reach the widest possible audience. As with any standard practice or technical standard, it is only as good as its applicability to any specific scenario.

So the question here is what value the purely generic information has; the answer is, as in other cases; it can be an excellent starting point but it should never be the destination. For example, XML or JSON represent different approaches for forming data messages, yet knowledge of the core JSON or XML standards is only valuable in the context of how it might be applied to your own data (which standard to choose, and how it will be used, structured and integrated into your solution).

Far too many Data Architecture projects present the generic information without the follow-on "contextualization." This is a sure path to project failure.

Mistake 2 - A Disconnected Approach
Where does Data Architecture start and where does it end? This is more than an interesting philosophical question. If one stops to think about it for moment, it becomes clear that there is data lurking nearly everywhere in the enterprise - yet much of it - perhaps even the majority of it is not officially managed as part of the "Data Architecture." This can include the following types of data:

• Email and content (including Social Media)
• Metadata
• System logs (for all / any type of systems) 
• Portfolio Management or EA tools
• Smaller DBs or tools not officially managed by the IT department (often business users)
• Mobile and Web App related data 
• Applications (commercial software packages) that have their own databases
• Device data (and / or embedded databases) 

Obviously, there will be situations as a Data Architect where you'll be asked to focus on only one particular 'slice' of the overall data environment for an organization. However, this mistake is more directed to the larger question as to how the enterprise views data architecture and data management. If an organization views portions of its data assets to be outside the enterprise processes associated with data management - then there is a problem. There is also a problem when the management of data is further divided across semi-autonomous groups within the organization. Both of these are very common practices today.

What occurs on these situations is the creation of data silos or islands. The natural consequences of that includes:

• Duplicative data across the enterprise 
• An inability to deploy truly effective analytics
• Significantly higher costs for IT

The easiest way to tear down these walls and connect the data islands is to make the commitment up front that the Data Architecture will include all data meaningful to the organization so that design and management can be aligned with enterprise goals and expectations.

Mistake 3 - Lack of Actionable Governance
Note that we didn't just say 'Governance.' Everyone in the data business loves to talk about Governance, but what does that really amount to? Governance tends to be both a workflow process as well as an associated toolset. If either the tool or the workflow process has limitations or is not present, the Governance effort generally fails. When we say "Actionable," what we mean is very specific; it involves the following elements:

1. Integration of Data Governance with all pertinent system management processes.
2. Integration of Data Governance with security standards and processes.
3. Integration of Data Governance and Portfolio Management process.
4. Integration of Data Governance and Data Architecture.
5. Adherence to clearly defined metrics, tracked on a continual basis. (this can include ALM metrics, integrity metrics as well as performance metrics).
6. The Governance process has clearly defined roles with authority and decision gates built in. 
7. The Governance is closely aligned to both tactical and strategic organizational goals.

This set of elements goes well beyond what many groups consider Governance. Often times this happens because they aren't willing to make the investment in order to support these activities. Ultimately any perceived savings are in fact highly illusory given the well-defined cost impacts of environments suffering from a out of control data sprawl (which always seems to come as a surprise but really shouldn't - recreating the same solution 4 times costs 4 times more, right?).

Mistake 4 - Data Architecture isn't Taken Seriously
As you might imagine, this is a problem not limited to Data Architecture. So, what do we mean when we say Architecture isn't taken seriously? This tends to manifest itself in the following ways:

• No investment at all in architecture
• Limited or one-off investments (periodic reviews but no dedicated architecture practice)
• No investment in architecture tools
• Lack of integration between architecture and other key processes, such as Portfolio Management
• No architecture methodology employed

Architecture is like anything else - you get out of it what you put in it. If the resources and commitment to an effort is minimal, it is likely that the value derived will be less than may have been expected (unless it was understood to be a token effort from the start). In many ways, the Architecture lifecycle is similar to an ALM (application lifecycle management) approach. Architecture is design writ large - typically taking into account all potential aspects of a ecosystem of individual solutions. In this sense, it is very difficult to translate Architecture into Agile methodology except for time-boxing delivery expectations. 

But architecture without any methodology is simply ineffective. 

Mistake 5 - Product Only Focus
This one deserves a bit of caveat. If your project is narrowly focused on deployment of one particular product / technology, then it is obvious that the product architecture will be the primary focus of the effort. However, this problem refers to the larger enterprise. An important value that an IT Architecture effort brings to the table is the ability to abstract capability from the specific technologies that will ultimately manifest that capability. What is this important?

1. Because in a large environment, there will likely be dozens of technologies involved.
2. Because technologies and products change. 
3. Because the Architect is not generally an agent or advocate for any particular technology, but rather an unbiased 'change agent.' This role is also referred to as the "Honest Broker."

So, the mistake that occurs most often in relation to this issue is the idea that one product or technology will provide some sort of "Silver Bullet" solution that will remarkably transform the enterprise. While this does on occasion happen, it does not happen very often. Generally the scope for any Data Architect will be wider than one product or product suite (or even several), and most importantly the true scope is the problem space associated with the organization's goals rather than mere management of specific commercial software packages.

We will cover the next five mistakes in an upcoming post...

copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Security Architecture, Defined

There are some people who don't recognize Security Architecture as its own niche within IT Architecture, but given the number of roles / positions now using the title "Security Architect," perhaps the naysayers have missed out on something. This post will examine what Security Architecture consists of and how it fits within the larger context of IT Architecture.

Back in the old days, security was a lot easier. We didn't have internet connectivity everywhere, few if any viruses, and only a handful of hackers who were mostly in it for the fun. Things have sure changed. What used to be referred as "Information Assurance" or IA has gradually morphed into "Cyber Security." While IA was primarily focused on management of information assets (which included copious amounts of paper locked in vaults), Cyber Security has tentacles that reaches all the up and down every solution stack and into every nook and cranny of the newly dubbed "Internet of Things." (this year's hype king).

Security Architecture is related both the practice of Cyber Security as well as the practice of IT Architecture. We've tentatively classified it as a subset of Solution Architecture, but just like some other areas like SOA, Security Architecture proves to be a bit ubiquitous in both principle and practice. Originally, when those of us worked on Security Architecture projects, we tended to fund them primarily concerned with Data Center design (or consolidation) or more specifically focused on tightening up perimeter security within a Data Center. Now, Security Architecture has become much more expansive, including aspects of UI coding all the way to management of mobile devices (to encrypt data at rest and prevent identity theft for example). So lets move on to some definitions.

Security Architecture, Defined

Security Architecture represents the ability to represent and resolve any IT-related security issues using IT Architecture techniques. These security issues can be internal or external and can either be technology agnostic or technology specific. The solutions developed as a result of Security Architecture analysis and design are often decomposed into "Security Controls," which focused on narrowly defined portions of the overall security landscape. 

Security is still based on core IA principles but those have been expanded
 to include a much wider arena of potential action

In our initial definition, we alluded to something called Security Controls; this is worthy of further examination...

Security Controls, Defined

Security Controls are the individual measures necessary to mitigate specific security threats or concerns. These controls can be part of larger information security standards (NIST, FISMA Cyber Framework, etc) or they can be defined within specific organizations (or a combination of both could be used). The controls consist of guidelines and policies (for example, coding practices), specific configurations for systems, and test cases for security evaluation.

Management of Security Controls isn't necessarily a Security Architecture function, however definition of Security Controls often is (coming after some type of audit that may include review of the existing architecture).

Which brings us back to the larger question of what Security Architecture is and what exactly a Security Architect does. As we alluded to earlier, once upon a time it was common to associate Security Architecture with data center technology (like Intrusion Detection Systems for example) and Information Assurance with control over information or data. Today, Security Architecture spans the entire stack from infrastructure (Cloud or Traditional) through Data, Application up through to UX. It also extends out to other enterprises and to mobile platforms and social media (or other external Cloud based services). Security Architecture is always only as strong as its weakest link - and with the ever-expanding scope of operations the extent of the oversight necessary to mitigate those weak links makes the job of the Security Architect more daunting than ever before.

Security Architecture must facilitate both prevention of threats as well as active oversight of operational integrity. While the Security Architect does not sit in a NOC (Network Operations Center) he or she does often determine how operational analysts will conduct their jobs. This field within IT Architecture is an excellent example why cross-domain expertise is needed for many Architecture roles.

We will be examining a number of specific Security Architecture case studies in future posts here on the IT Architecture Journal.

copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

How to Create Product Maps

In some of our articles here you've probably noticed various types of diagrams thrown in as examples. All of these come from real-world project related exercises. When an IT Architect produces a diagram we generally refer to it as an "Artifact." While this may sound like we're talking about relics, it is simply an odd naming convention of our industry. An Artifact can be any sort of deliverable; a Word doc, a spreadsheet or perhaps even a file associated with a specific EA software environment. The common thread across any of these deliverable formats is the notion that the Artifact must be more or focused on one topic (sometimes this isn't the case, but most times it is).

One particularly interesting type of Artifact is the "Product Map." So what exactly is a Product Map? Well, there are two distinct types of Product Map and there are only tangentially related.

Type 1 - A Map showing the relationship between products, comparison of products or elements of a complex product suite.
Type 2 - A Map showing product components and their evolution (past and future roadmap).

So, you might be asking yourself, why is such a thing necessary and what does this have to do with IT Architecture?

Why We Need Product Maps
Believe it or not, the companies that produce these products don't always do a good job at depicting the composition of their products or the relationships between products. And, if we extend our view to a large heterogeneous enterprise environment, there is little incentive for a product company to spend too much time thinking about how their product might relate to their competitors or other products which don't seem to be related to the function their solution performs.

There are a variety of situations where product maps might be needed; they include:

• Representation of "As-Is" architecture. Product maps would be drill-down artifacts that illustrate more of a physical view.
• Product Evaluation and Source Selection efforts.
• Transition Planning exercise (in other words, being able to illustrate migration of one set of tools to another).
• Enterprise Integration Design. Getting different product sets to work with one another or even send messages to other can be challenging. 

The product map differs from other types of architecture artifact in that it depicts some aspect of a larger solution from a specific product perspective or context. The way we might highlight an identity management solution in an agnostic logical view could look far different than a product specific IAM stack (see the diagram below).


IT Architecture & Product Integration 
So how does the IT Architect facilitate Product Integration? Well, at its core this represents a problem solving exercise; in fact one of the more complex ones that the majority of enterprise tend to face on a routine basis. One might think that since so many similar organizations face this type of challenge that there would be a wider set of industry standard approaches to this - but this isn't the case. While many enterprises share the same tools, the exact configuration and inventory will almost certainly vary widely. And as most of you know, even moving from one version of a product to the next can be major hassle in itself.

The IT Architect takes this problem and turns into a design exercise. This begins by documenting all of the pertinent aspects surrounding the product:

• Key features
• Standards support
• Administrative and management considerations
• Customization support (languages, configuration)
• Inter-operability mechanisms (database connectivity, APIs, etc.)
• Version control and version specific variations of the above
• Overlap of features or deprecation of features (either between different versions or options of one product or competing products).

The Architect then defines all of the related design decisions based on a larger set of expectations for how the product might be used. Some products of course merely provide a platform for even more custom development (for example an DBMS like Oracle) - with the larger Oracle stack then there are opportunities for both custom and packaged analytics. The determination as to whether to go one way or the based upon what products are already in the inventory or which ones ought to be included near-term and long-term is a classic example of contextual product mapping.

An example of a product map of a suite of related security products

IT Architecture & Product Design 

Can IT Architecture support product design or development? In a word yes. This represents Type 2 Product Mapping. For example, what if you had an excellent idea for a new mobile app and wanted to manage it in some start-up scenario? There are of course various business considerations for a typical start up, but just as important is management of the product itself and that should start with its architecture.

The architecture will drive many key decisions related to the product's introduction and evolution including:

• Determination of what technologies should be harnessed to actualize the product.
• Development of the product roadmap (including conditional variations based upon contingencies or opportunities).
• Determination of key systems design options and solutions.
• Governance of the product (and all its related infrastructure and code) across its lifecycle.
• Determination of product synergies in the market (the larger ecosystem of related solutions).

We will look at Architecture and Product Design in greater depth in upcoming posts here on the IT Architecture Journal.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Lifecycle Management, Defined

Like many other aspects of Information Technology over the past 15 to 20 years, Lifecycle Management has evolved quite a bit. In fact, it didn't generally even get referred to as "Lifecycle Management" until about ten years ago. It (both the term and the practice) has become more expansive in nature as time has passed. This is an interesting not just due to the evolution which has occurred to the surrounding practice, it is also the one area in IT where technology and business / management comes closest to being blended into one concern.

Lifecycle Management is also the reason that IT Architecture exists the way it does today - without the driving force of various governance processes and mandates, IT Architecture would have likely never quite crossed the threshold from systems or software engineering and design. We'll return to that in a minute.

So time for definitions - and in this case - a hierarchy.

Lifecycle Management, DefinedLifecycle Management is the practice of coordinating all the related activities for any given selection of IT capability (within or across organizations). There is generally a hierarchy for these activities which falls roughly into the following structure; Portfolio, Program, Project. Generally at the Portfolio level, the capability management spans many systems whereas there may be multiple Projects supporting just one piece of software or one system. In an optimal situation, all Lifecycles should be unified based upon shared methodology, principles, goals and supporting tools. 

Many people have long considered Lifecycle Management to be the province of the manager. However, nothing could be further from the truth. For Lifecycle Management to function as intended there has to be a partnership between management and technology resources. This partnering usually occurs on the tech side through the role of IT Architect.

This view is a more traditional enterprise-focused view (mainly waterfall in nature) 

Why Lifecycle Management isn't just about Management
Let's go over a few things that must have technology input to succeed:

1. System (and project) Scope - While there may be a number of specific expectations from business, the most successful systems (and projects) are those in which the tech side helps to define the boundaries of what can realistically be done. This manifests itself at the highest level in portfolio roadmaps and at lower levels through statements of objectives or similar scope documents for projects (which then get passed through governance processes for approval). 
2. Project Estimation - This is a much more complex process than many realize. Good project estimation requires a precise understanding of the complexity of the technical tasks involved. Whether you're talking about building J2EE-based APIs or deploying a WCMS, the tech experts who have been there / done that are invaluable in helping to define a realistic project estimate. Since much of IT is measured based upon estimated cost versus actual expense - this area is disproportionately important. 
3. Risk Assessments - Sometimes this includes Architecture Assessments, other times it is more of a technology strategy type exercise.
4. Technology Selection - Should we Build or Buy, or if we're going to buy, how do we choose? These are the typical questions that get asked, but who can really answer them? The IT Architect, of course - its part of their job description.
5. Solution Decomposition - This is related to project estimation but more detailed. Generally, somewhere within a planning process, there is a preliminary design exercise which goes as far as determining how best to 'break up' elements of the intended solution into digestible pieces. This also involves prioritization - understanding which parts have to come before or follow others due to various technical dependencies or constraints. 
6. Project Oversight - This is a big topic, one we will dedicate other posts to, but for now we'll just introduce it. IT Architects often play a semi-leadership role within individual projects (as a project or solution architect). This is so technical issues can be tracked, managed and mitigated with continuity across all phases of the individual lifecycle. 
7. Enterprise Integration - This is without a doubt the hardest part of the overall set of potential Lifecycle Management related activities. Now, many think of Enterprise Integration as a purely code focused or networking relating topic - believe me it's not. Enterprise Integration is in reality the intersection of potentially overlapping systems, data and expectations. The most important aspect of Enterprise Integration is inter-operability design  (which comes in many, many forms). It's a study in complexity and not for the faint of heart. 

Let's step back for a moment and explore Lifecycle Management from a different angle. In previous posts we've been talking about methodology a bit; Agile, Waterfall and so on, but what does it all mean? The short answer goes something like this:

An IT methodology quantifies the workflow or lifecycle steps necessary to provide consistent support for system development and management. Most lifecycles share the same common elements; a planning phase, design phase, build phase and implementation phase. And yes even Agile has all of these. Within the common framework, there is a massive amount of variation. So, if you ever had to work with Carnegie Mellon's CMMi (waterfall spiral methodology) and then were put on a Scrum project (Agile variant) it would be like moving from Iowa to Italy - a culture shock to be sure. 

In today's terminology, you often hear the term Application Lifecycle Management (ALM) used - it is essentially the same thing as Software Development Lifecycle (SDLC) except perhaps that today an ALM can encompass both Waterfall and Agile whereas before SDLC was more Waterfall focused. So what are Waterfall and Agile, anyway? 

Waterfall - this refers to both purely linear and 'linear iterative' development methodologies, wherein requirements are more fully defined up front and allocated to segments in a somewhat sequential manner. In some cases, code is completed and tested in iterations - other times no capability is delivered until the very end (traditional waterfall).

Agile - Up front design is minimal, few if any requirements are formally development. The focus is the production of working capability with each (very short) iteration. Design in this model becomes iterative in that core assumptions can be readdressed and correct "in flight" (which is why up front requirements become redundant or unnecessary). 

We will be talking a lot more about 'Agile' and 'Waterfall' as we progress on the blog. 

Lifecycle Management has evolved from a set of competing software development methodologies to become a potentially all encompassing set of technology management processes for the enterprise. And it will continue to evolve with the IT Architect maintaining a key role for some time to come.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Aligning Lifecycle Methodologies - Part 1

In a previous post, I contended that requirements are still an important part of most enterprise environments, even those that might be using Agile lifecycle methodologies. However, I didn't specify exactly how those requirements should be captured — or even what constitutes a requirement. This is an important question when determining how to align multiple lifecycle approaches within one organization (the need for which is much more common than most people realize)

This question encompasses two major lifecycle approaches; Agile and Waterfall methodology. Many organizations feel that User Stories (Agile) are sufficient to build both code and project structures around them. Is it out of the question to consider that Use Cases might be used within an Agile approach?

Before answering that, let’s take a look at User Stories, Use Cases and Requirements in context again:

• A User Story can be thought of as a high level or conceptual scenario, or perhaps just a problem. An example might something like this: A user needs to be able to save a report into multiple file formats for downloading, including both .pdf and .xls. Even though we’ve described two different formats, it still represents the same scenario or problem.
• A Use Case, on the other hand, can be considered a functional requirement. The difference between a functional requirement and technical one is the level of detail the document includes about how specific actions are carried out. For example, a use case would capture the process flow, or steps involved in generating the report and the expected outcomes or alternatives. This helps to build test cases later on. A use case is slightly more structured and detailed and is generally written by someone IT or in combination with the IT group. That way, some of the technical expectations are captured. In other words, the use case describes not just behavior, but how that behavior is achieved.
• A Requirement in this context refers to a technical requirement. This is entirely specific to the elements needed to develop and/or deploy the capabilities described in the previous two documents. It allows us to formalize performance constraints, data elements and other pertinent technical details. This is especially important in environments where EA, service or data governance paradigms are in place. If written properly, requirements can then serve as system documentation.

Mapping across lifecycle approaches begins with requirements (however they're captured)

While many organizations practicing Agile bypass requirements, they may in fact still capture the same information after the fact if they actually document their deployed solutions (after the fact). When you’re considering whether or how to employ user stories and use cases, keep these points in mind:

• They are not the same thing.
• The user story ought to come first.
• The use case ought to be derived from the user story.
• Any requirements managed from this process should be embedded within, or otherwise traceable to, a specific use case and user story.
• User stories could be considered either scenarios, high-level processes or problems.
• Every organization approaches this process somewhat differently. For example, in a less Agile environment, a number of other architecture artifacts could be added to the illustration above:
• At the user story level, many people like to capture a data-flow diagram or a context diagram.
• At the use case level, many folks like to add a UML sequence diagram and conceptual data model.
• At the requirement level, many UML diagrams are often added including activity models, state models, component diagrams or deployment diagrams.
• If a formal EA framework is being applied, those UML or ERD diagrams are often replaced or folded into EA Framework views/artifacts.

Getting back to the original question — should use cases be used with Agile lifecycle management? — my recommendation is yes. Here’s why and how.

Why to Do It

1. It ensures some level of systems engineering is included in the Agile design process.
2. It helps to define the tasks associated with each user story and doesn’t add that much extra effort - it also doesn’t require a use case diagram (which in most cases doesn’t convey that much meaning anyway).
3. It ensures that both IT and business stakeholders capture their expectations in formats tailored to their roles and needs.

How to Do It

• Define your use case template and what it must convey.
• Determine whether user stories require more than one use case. It happens occasionally, although in most situations user stories should be in a 1-1 ratio.
• Ensure that someone from IT helps with, or provides much of the detail, in the use case.
• Ensure that use case development is aligned with both the quality and testing paradigms. This is especially important if no requirements are captured.

The majority of Agile development environments are fairly flexible in regards to storing of related attachments, so the biggest impact to employing use cases along with user stories is in the design and development process. This is the first step towards aligning lifecycle methodologies; we will examine this further in several upcoming posts.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Understanding Architecture Accessibility

The topic of Architecture Accessibility may sound a bit abstract upon first glance, but it is in fact one of the most important considerations as to whether an architecture effort will add value or not to an enterprise (or any particular solution lifecycle). It is also directly related (or perhaps a part of) the most important consideration for any architecture - its usability.

Let's step back for a moment and paint the background a bit.

IT Architecture has progressed in fits and starts over the past 20 years or so partially because of the widely varied results or outcomes associated with its practice under various scenarios. This is to be expected when considering that this is a fairly new aspect of Information Technology - it appeared rapidly and has been evolving ever since.

But why has IT Architecture sometimes gotten a bad reputation? The common causes for this include the following:

• A lack of clear expectations as to what the Architecture activity would really provide.
• A lack of connection between different types of Architecture efforts - for example Solution Architecture being managed separately from Enterprise Architecture or Data Modeling or application design not being considered as architecture.
• A lack of integration with governance and portfolio planning and management processes. 
• A lack of detail and / or specific implementation-level guidance.
• A lack of integration between architecture activities and ALMs / SDLCs (Software Development Lifecycles) 

You may have recognized a common thread in most of these problems - that organizations which produce Architecture in a vacuum seldom succeed. A variation of that theme is directly related to our core thesis on architecture accessibly.

Making Architecture accessible requires clear organization and a componentized, targeted approach

What is Architecture Accessibility and Why is it Important?
Accessibility in this context refers both to how people can reach the Architecture but also to how it is structured. So, here is a fundamental consideration - if an Architecture is produced yet few within the larger organization have access to it - how likely is it that the Architecture will achieve its originally intended purpose? Taken a step further, if we examine the structure issue; how likely is it that an Architecture will be exploited efficiently if it is difficult to find the pertinent information within it that any given stakeholder might need?

As Architectures grow in complexity, there tends to be a larger and larger potential audience associated with it. For nearly everyone in that audience, only a portion of the Architecture will be relevant to them. Thus the idea of a monolithic architecture artifact (say, a giant MS Word doc) becomes highly problematic. Use of a formal Enterprise Architecture repository can become equally problematic if added licensing is required for anyone who needs to view the Architecture (which in my view is a highly counter-intuitive strategy on the part of companies which produce such software).

What is at risk if Architecture becomes inaccessible is "Shelfware Syndrome." Architecture like software can provide no value if isn't applied to something - it has to be used. And this is how we begin to make the connection between Architecture Accessibility and Usability.

Architecture Usability, Defined
"Architecture Usability" refers to the ability for the Architecture to communicate the right level of information to specific stakeholder groups. Architecture must generally support multiple stakeholder groups simultaneously. What proves to be 'usable' in one specific organization may be different than in another, but generally it will involve a mix of descriptive (design explanation) and prescriptive (implementation guidance) content. Usable Architecture then is technical design content which is structured such that it can be easily accessed by the right audience at varying levels of detail.

Architecture is a continuum - it provides a mechanism whereby any number of projects and systems can be tracked and managed in context with one another. It represents a sort of meta-integration mechanism if used properly and the best architectures are those which are fully integrated within the organizations they serve. Good Architecture is Democratic as well in that the wider the shared designs are disseminated, the more likely it will be used effectively to guide the enterprise towards a unified set of goals (and some tangible end-state payoffs).

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More