10 Secrets of Cloud Architecture

Over the past year or so, the demand for Cloud Architecture has soared. This can be assessed simply by looking at requirements for full-time or contract positions related to Cloud Architecture. Even those IT Architecture roles not directly defined as being Cloud Architecture often now tend to include Cloud related qualifications. So, one has to wonder, why the recent upsurge in activity? And by the way, what does Cloud Architecture really represent these days? I'll try to answer this with a list of secret insights from an Architect on the front lines - and if not secrets - at least with unique perspectives:

Secret 1 - Cloud Architecture has morphed into a holistic field that encompasses not just AWS, Azure, Rackspace etc. features, but nearly all considerations faced by IT. It is now the new enterprise architecture - the traditional internal environment is just one of many which must be managed across a variety of barriers in a logically consistent manner.

Secret 2 - There is no such thing as a hybrid Cloud anymore. Nearly all IT environments have elements of internal and external cloud capability (e.g. any infrastructure group that uses virtualization can qualify, whether they have elastic computing or not. Also, most private Cloud frameworks are externally managed anyway). It is now simply a Cloud or Enterprise Framework.

Secret 3 - Cloud is not just Infrastructure. The days of thinking of Cloud as the IaaS or PaaS or even SaaS are mostly gone.  This has profound implications in regards to who should manage Cloud capability and how. To borrow a phrase from Data Architecture - Cloud capabilities represent "Enterprise Assets" and can no longer be managed in silos by individual IT service groups or business units.

Secret 4 - Yes, you need a Cloud Strategy. While it may sound obvious now, remarkably it hasn't been and still isn't in many quarters. This ties neatly with the enterprise data analogy but in reality also involves enterprise data, enterprise security an much more. I will talk more about Cloud Strategy in another post.

Secret 5 - The Cloud allows you to fail fast, take advantage of that. There are things that we can do with the Cloud at a fraction of the cost it would have taken to do even 5 years ago. The Cloud allows for much more rapid deployment and adjustment than traditional IT, but to take advantage of that, one has to acknowledge it in how new capability is approached. One way to do that, is to use part of your Cloud framework specifically to assess capability - an Innovation Lab of sorts. I will address this in a future post.

Secret 6 - The Cloud introduces new cost paradigms which need to be fully thought through in order to take advantage of. This is another good reason for the strategy. Not everything on the Cloud is cheaper, there needs to be serious consideration given on how to leverage existing licensing and equipment with oncoming Cloud capabilities.

Secret 7 - There will always be more than one Cloud to deal with. As great as AWS is in introducing more services than we ever thought possible, there will likely always be a legitimate need to include other Cloud offerings in your portfolio; whether it is Google, Azure or some SaaS solution or new capability that hasn't been released yet. And btw - there is no such thing as a Cloud portfolio - it's just your Portfolio - which from now on will include Cloud capability.

Secret 8 - To be a Cloud Architect, you in fact have to be an IT Architect. So, for example, if you want to be a good AWS Architect, you must understand; Networking technologies and concepts, Identity & Access Management, Devops, Server Management, Storage Management, Virtual Desktops and more. Specializing in AWS in fact makes one quite the generalist.

Secret 9 - To be a true Cloud Architect, one must have experience with multiple Cloud offerings. While the technologies and concepts are often similar, this extends the generalist notion even further.

Secret 10 - Cloud Architecture has infiltrated most other areas of architecture. Let's say you're an MDM architect looking to deploy Informatica, Infosphere, Stibo, Talend or some other MDM tool. In every case, there are now Cloud related aspects to the deployment options. Eventually every Architect will gain some Cloud familiarity whether they want to or not.

As I said, perhaps these insights aren't trade secrets, but taken together they represent an interesting new paradigm that not just architects have to contend with. Today's Cloud represents both a logical progression of key technologies as well as aggregation of those in new ways. The enterprise processes and practice to define, design and manage this new Cloud paradigm has somewhat lagged behind the capability. Cloud Architects will help lead the way in closing this gap.


copyright 2016, Stephen Lahanas

Read More

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

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

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

Exploiting SharePoint as an Architecture Repository

Enterprise Architecture (EA) as a practice has gained quite a bit of traction over the past decade. Where EA hasn’t taken root yet, Solution Architecture is often practiced. One of the biggest challenges to the adoption of any type of IT Architecture practice or department is the ability to integrate it into the larger solutions lifecycle of any given organization. This is typically a challenge for the following reasons:

1. The culture of the organization isn’t sure about the value proposition for architecture.
2. The working model between architects and the rest of the solutions team isn’t always clear at the beginning.
3. The architecture practice / department lack the tools to do its work or properly communicate back to the rest of the organization.  

Of these three elements of the problem, we’re going to focus on the last one. Usually, there is always some level of resistance to doing anything new within an IT group and of course it takes time to find the right working models for how to implement new processes or capabilities. In the case of IT Architecture, having a tool available at or near the start-up of  a practice makes a huge difference though in helping to resolve the first two issues and ultimately will lead to greater overall success of the endeavor.

SharePoint as a repository is basic - but it does meet several core requirements

Architects tend to use a variety of tools to do their jobs; for example a typical EA may utilize the following software to support a typical data architecture project:

• Microsoft Visio – for free-form design / modeling
• CA ERwin – for ERD or dimensional modeling
• A UML tool – for developing Use Cases, Sequence Diagrams etc.
• Specific tools to support individual software packages (BI, Hadoop)
• Ontology Modeling or mind Mapping
• Network Design tools

All of these tools produce their own architecture “artifacts” or files. There is a also a class of software out that specifically tries to unify all of this information by providing both design interface and architecture repository. The best known of these tools includes IBM System Architect, TrouxMetaverse Mega and Sparx EA. There are quite a few advantages to using this type of software but surprisingly few architecture practices actually deploy them and often when they do try to deploy them they don’t “stick.” In other words, some aspect of the deployment fails or adoption is restricted for other reasons – for example due to a lack of licensing to make the architecture accessible to all of the stakeholders who actually need to be involved. So what happens when an organization deploys an IT architecture practice without any dedicated tool support for it?

In many cases, when an architecture group isn’t given clear guidance on what tools to use; the ability to define and develop clear processes becomes highly problematic. One of the first things an architecture practice or department ought to be doing is defining exactly what patterns or designs are standard for that organization. This set of decisions then tends to manifest itself into design templates in whatever tools happen to be available. Without any standard tools then it almost impossible to accomplish this vital step. Without standard views of the design patterns, then the ability to consistently capture design and apply it in a uniform fashion across projects suffers. The lack of design tool also tends to imply not having a repository as well. Without a repository, architecture artifacts then get managed as content by whatever means may be available in the enterprise:

• Shared folders
• CMS or portal
• QA or other backlog or PLM tools

Of these available options, the use of an existing Content Management / Portal capability represents the best opportunity for organizing an Architecture practice when a dedicated architecture  repository tool is unavailable. Shared folders have access issues and a serious lack of functionality and many QA/PLM also tools share the same cost issues associated with architecture repositories. While any CMS / Portal will work for what’s being described here; I’ve zeroed in on SharePoint due to the sheer volume of the enterprise organizations now using it. Those organizations that don’t already have

SharePoint deployed internally now also have access to SharePoint in the Cloud on Office 365 at fairly reasonable rates (although it takes a while to figure out how to order and configure the options focused on SharePoint only).

SharePoint isn’t always the easiest tool to work with, but it does support some of the key capabilities needed to help establish, unify and organize an IT Architecture practice; those include:

1. The ability to save and version control any type of content.
2. The ability to support complex publishing (e.g. through a basic wiki). 
3. Some application capability (in this case, through the use of List web parts in SharePoint).

While many or perhaps most installations of SharePoint don’t really support Collaboration very well, the SharePoint online solution is now being bundled with Yammer which opens this open up as the 4th major capability. Once you have your architecture “platform” in place, you can go back and align your designs process approach with the “public face” of the practice. A typical SharePoint Architecture site might include the following elements (see the diagram below):

• A Design Pattern Wiki – This is how stakeholders can access your architecture.
• A Business Glossary – This can include the ontology and core business terminology.
• Data Dictionary – This is where architecture meets data; very few organizations have comprehensive data dictionaries, even fewer make them available publicly.
• Architecture Governance Portal – Architecture requires both technical and business input – that Governance can be managed using simple web part Lists for tracking, approval etc.
• Technology Catalog – While SharePoint is not recommended as a comprehensive IT asset management solution, it can be used to capture all reference architectures and information about deployed technology (using a wiki and / or lists). 

In an upcoming post, we will talk more about how architecture patterns are managed using this type of approach or traditional EA repositories.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Understanding EA Frameworks

Enterprise Architecture by nature has a broad scope. In a sense, the typical Enterprise Architect is being asked to describe all things IT-related about any given enterprise in the course of their routine duties. What Architects determined fairly early on (in the relatively brief history of IT Architecture) was that this descriptive process is in most cases similar across organizations. And this realization is how the concept of Architecture Frameworks was born.

Before we begin defining EA Frameworks in greater depth, it is important to clarify what frameworks don't represent:

1. Frameworks are not design notation - so that's why we haven't included UML.
2. Frameworks are not ready-made solutions for the enterprise.
3. Frameworks are not design patterns. 

I will explain these clarifications as we proceed through the topic.

This is an example from an EA project using both the DODAF & FEAF Frameworks

EA Frameworks Defined

An Enterprise Architecture Framework is a meta-model for characterizing all IT related capabilities present within any given organization. At the heart of this model is a taxonomy that differentiates core capabilities into approximately a half dozen or so categories. These categories usually include; Business, Application, Data, Infrastructure and so on. 

By characterizing the enterprise in this type of meta-model, the Framework facilitates the ability to construct standard views of the enterprise (visual / diagrammatic or otherwise). The Framework provides even more value if translated into a repository-driven software tool that allows for all specific enterprise information to be captured and stored within the industry standard meta-model format (which then supports inter-operability / information sharing across organizations).  

All EA frameworks share these common features or goals. There are only a handful of Frameworks being used across industry; they include:

• Zachman - Arguably the first real Framework
• DODAF - Department of Defense Architecture Framework  (MODAF for Europe / NATO)
• FEAF - Federal Government (US) Architecture Framework
• TOGAF - The Open Group Architecture Framework

Each one of these have their own unique variations - two are more industry focused and two are primarily government focused. There are about a half a dozen tools dedicated to providing software support for EA frameworks and these include:

• System Architect
• Mega
• Sparx EA
• Troux (formerly Metis)
• Archimate
• ProVision

There are other tools, but ones listed above are most commonly used.

The Difference Between Design & Enterprise Architecture
Earlier I hinted that EA and design are not quite the same - especially where Enterprise Architecture Frameworks are concerned. This is in fact the same dichotomy we've introduced in our other posts regarding the difference between EA and Solution Architecture. If we want to describe the entire enterprise, then TOGAF provides a good medium for accomplishing the goal, but if we wish to describe or define a database schema then we'd look at using ERD or Dimensional Modeling techniques. If we wanted to design an application, then we'd use UML design notation and perhaps a pattern-based architecture approach.

How we coordinate or reconcile EA with Solution Architecture is a big topic and we will address that across a number of posts in this blog. We will also define in greater detail the other terms introduced here today.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

How to Set up an Enterprise Architecture Practice

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

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

1. Internal Architecture Management - This mission is focused entirely on supporting internal processes, systems and infrastructure. While these solutions may themselves facilitate core client-facing business capabilities, 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 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Can Enterprise Architecture be Agile?

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

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 Agile 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.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Difference Between Enterprise and Solution Architects

I'll preface this topic by stating up front that very often Solution Architects (SA's) and Enterprise Architects (EA's) are the same people. There's no reason why EA's and SA's can't fill each other's roles and in fact this happens quite a lot. Having said that though, there are differences between the type of work you'll be asked to do as a Solution Architect from the tasks you'd be asked to perform as an Enterprise Architect. It is also important to keep in mind that both roles share common skill-sets which is why both roles can be grouped within the umbrella title of "IT Architecture."

We'll start by providing some definitions:

1. Enterprise Architect  -  An Enterprise Architect is someone who is charged with helping to define cross-domain capabilities and solutions for an organization (or in some cases just documenting them).  An EA is definitely a big picture role - one focused on how issues, projects and systems relate to one another in ways that aren't immediately obvious to those working within the context of individual projects. EA's are often also asked to establish, populate and otherwise maintain enterprise architecture / knowledge repositories.  These enterprise architecture resources are used as a Reference Framework or starting point for all other IT activities (when it's done properly, that is).

2. Solution Architect - A Solution Architect is someone who is charged with defining and usually implementing specific technology solutions.  This role is often referred to as a Project Architect, but can just as easily apply to any type of IT resource referred to as an "Architect" (e.g. Data Architect, SharePoint Architect, Security Architect etc.). The SA role is more focused on software development lifecycles (ALMs) than the EA and is often tasked with following a solution throughout that entire lifecycle (be it months or years).

If these definitions sound a bit open-ended, they are - but that's primarily because this is how they're viewed by employers.  The SA role in particular is fairly hard to pin down because almost any IT specialty these days can have an "Architect" role assigned to it. As the SA role becomes more technology-specific, it moves further away from the generic vision of an IT Architect who could conceivably move back and forth between and SA and EA roles. For those who aren't completely invested in one specific technology though, there does exist a common set of capabilities or skills that both EAs and SAs tend to share:

• Problem-solving or analytic reasoning - This is often referred to as "Critical Thinking" but unfortunately academia has never quite standardized what that means. For our purposes, "Problem-solving" refers to the ability to apply one or more problem-solving methodologies to bear in order resolve any type of technical issue (it can be a personal problem-solving approach or one associated with any number IT methodologies). 
• System Engineering Skills - Often times people lose sight that architecture is in fact an engineering as a well as design-focused discipline.  Systems Engineering helps provide the ability to think through constraints, dependencies and relationships. It also provides valuable insights into how standards are developed and deployed.
• Design Thinking - This is a bit of a buzz-word but it helps to emphasize the creative nature of architecture. Analytic and System Engineering skills will only take you so far; creativity brings you the rest of the way.

Any Architect who works or has worked across multiple technologies, either as an SA or EA will have equal application of the skills listed above. The number one skill though for any EA or SA is this - the ability to take those common skills and apply them to an entirely new technology or problem.

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Enterprise Architecture Defined

When examining the various flavors of IT Architecture it is worthwhile perhaps to start at what some might consider the “top.” By Top, we don’t mean the best or most difficult but rather the top level of architecture – e.g. that level which has an enterprise level or higher (cross-enterprise) scope. Many people define Enterprise Architecture (EA) differently, but the common thread that passes through all definitions is scope and reliance on formalized “Frameworks.”  Also, many EA practitioners view themselves as architecture integrators who provide oversight across all types of design work done within their respective organizations.

Other key considerations about EA include:

1. Most people who know about EA think of it in terms of the “Frameworks” which are used to produce EA “products” or “artifacts” (the output of EA). 
2. Frameworks represent design and notation paradigms and are generally supported by meta-models constructed to emulate IT enterprise environments.
3. Frameworks include: DoDAF, ToGAF, FEAF, Zachman, UML, MODAF, BPMN & BPEL, IDEF, C4ISR, ITIL…

Enterprise Architecture as a practice is most often associated with higher level processes such as Portfolio Management, Acquisition Management (mainly government-focused) and IT Strategy. EA artifacts tend to be more conceptual in nature with the expectation that the higher level description drives lower level designs (Solution Architecture) and artifacts. EA is also often times viewed in a more agnostic fashion in regards to specific technology than Solution or Infrastructure Architecture. 

This diagram illustrates how EA framework considerations might be reconciled with solution architecture elements

We will define EA frameworks in an upcoming post...

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More