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

What Does an IT Architect Do?

This is an interesting question for anyone thinking about working as an Architect but also for anyone else working in IT because there isn't a consistent set of definitions regarding architects within the industry. Architects who do more or less the same things with the same skills could variously be referred to as:

• Enterprise Architects
• Solution Architects
• Project Architects
• IT Architects
• Technical Architects
• Data Architects
• Application Architects
• Business Architects
• Cloud or SOA Architects
• Security Architects

And the list goes on. What if anything differentiates these roles (1)? More importantly, what elements do these roles have in common (2), if any? Not too long ago in the history of IT, few people used the term Architect to describe anyone. Why has this changed (3) – we've gone from no architects to more than a dozen flavors in perhaps 15 or so years?

Let’s answer some of these questions:

1. The Architecture roles (listed above) are generally differentiated by some level of solution specific expertise in one area or another. This could involve methodology, toolsets, skillsets or even industry domain knowledge.
2. An Architect is not or at least should not be tied to one specific element of expertise – if he or she is focused in only one area then they become a Subject Matter Expert (SME) and not an Architect. This is an important and practical distinction because technology keeps changing – today’s stack will not be the same as tomorrows’. Architects must understand the entire stack as it evolves and change skill sets as that evolution occurs. All Architects are designers. All Architects are problem solvers. All Architects are by nature also systems and business analysts. 
3. The genesis of the Architecture role in IT is directly related to the rapid decentralization and added complexities associated with the PC and Client Server revolution (and everything else that has occurred since then). In other words, as IT environments and systems became more complex, it was apparent that a “complexity manager” was required. That person is the Architect. 

Why would we necessarily refer to a complexity manager as an Architect? The metaphor as designer is obvious – but just as important is the idea that the Architect is the one who has the vision and understanding to see how all of the various pieces ought to fit together. An Architect, in either realm is by nature also an integrator.

So, how does an IT Architect differ from a traditional Architect (the folks who design blueprints for buildings)? Perhaps the most interesting difference between the two roles is that there is often an expectation within IT that the Architect or Designer is also the Builder. In the world of brick and mortar construction, it is very rare to see builders follow a career path from hanging drywall and pouring foundations to drafting the design for the entire building. Yet, in Information Technology it is relatively common to see developers become architects.

There is a good reason why this happens in IT but there is also a problematic result as well. The reasons why it happens are because:

1. the architecture career path is still unclear and we have to get Architects from somewhere and 
2. unlike with buildings, Architects in IT need to understand more of the technology associated with what gets built. 

We need that understanding because IT is much more dynamic than building design – we ‘reinvent’ our industry about every 5 to 10 years now. Some people still consider Frank Lloyd Wright’s work to be cutting edge and he’s been dead for more than 50 years – clearly IT and traditional architecture move at a different pace.

The problematic outcome of this situation is that many Architects tend to view the design and analytic processes associated with architecture to be inferior to ‘just building something’. This viewpoint more or less contradicts the true mission of what Architecture is supposed to do and the problem that it solves. In other words, Architecture has arisen to manage complexity; yet rapid build with minimal analysis is the number one culprit behind increasing complexity in the first place. This type of Architect could be referred to as an Architect in name only because it generally implies that they would not be practicing many of the key attributes associated with Architecture. This also potentially opens up a larger debate regarding Agile versus non-Agile IT, and that debate will never go away. The important takeaway from that debate though is when you reach the systems of system level; architecture becomes increasingly important.

Contrary to popular belief, Architecture and Agile Methodology actually complement one another.

There is a another consideration in understanding the role of the IT architect as well – without industry standard expectations in relation to what the Architect role actually represents – there can be wild inconsistencies across or even within organizations that utilize architects.  So, how could we solve this dilemma? Here are some suggestions:

1. Develop an industry standard set of role descriptions for IT Architecture. (there are groups that have developed standards for Enterprise Architects, but that is entirely too narrow to handle the larger set of expectations associated with IT architecture).
2. Ensure that any Architect in any role, anywhere – is given the top level training or expectations that are common across all architecture first (before drilling down). 
3. Help foster the distinctions between lead developers, tech leads, SMEs and Architects. This will help organizations determine when they really need an Architect as opposed to one of the other roles. If the roles are mixed it is highly likely that one part or the other of the combined role is going to get shortchanged – and that could lead to a number of unforeseen consequences. 

There are several other key attributes that help to distinguish IT Architects from other roles in IT; these include:

• Architects are often asked to act as liaison between other solution stakeholders. Sometimes Architects even become the official solution advocates.
• While sometimes asked to be advocates, Architects also tend to be the key resource in determining when a solution needs to be dropped. An Architect must be impartial when making such decisions.  
• Architects are complexity experts or managers – in other words typically Architects are dealing with “Systems of Systems” scenarios. Thus, the Architect has to be concerned not just with how the solution will operate in its own context, but how it will function in the context of the larger ecosystem. 
• Architects act as honest brokers in being able to question assumptions and drive change in order to mitigate potential risks. While other roles may be involved in this; typically Architects have the best vantage point to deal with it.
• Architects are change agents – more-so than any other IT role. Architects are asked to either envision or evaluate new technology and lead the move towards it.

The IT Architect is a relatively new role; it is often interpreted differently but it is uniquely positioned to become ever more important. As this role continues to help evolve the IT landscape, it too will evolve.


Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The 5 Rules of IT Architecture

It is perplexing that after nearly 20 years since the emergence of IT Architecture as a discipline, there is still so much confusion surrounding what architects do (or more precisely, what they are supposed to do).

Many people in IT refer to themselves as "Architects" now - yet how can employers or colleagues quantify or otherwise validate that they are indeed actually Architects? I will propose five simple rules or tests to help clarify this:

Rule 1 - Architects architect, just as writers write. Architecture is by definition a design process. Any architect who doesn't or can't produce design is not functioning in the assigned role. An important corollary to this is that you cannot be an effective Architect and focus only on one 1 thing in IT - for example 1 tool / product. Architecture is a discipline, not SME knowledge in one particular area. The reason why this is the case is that most of the time focus on one product leads to a very myopic view of how to solve a problem (every issue begins to look like a nail for your one hammer).

Rule 2 - Architects follow a design process; whether it is geared towards EA frameworks or application design is somewhat irrelevant. What is crucial is that an approach is followed. Not having an approach means not having standard design expectations or deliverables. A lack of design diligence is analogous to a brick and mortar architect using cocktail napkins instead of blueprints to design skyscrapers.

Rule 3 - Architects are honest brokers, not blind followers. Why is this important? Well, it matters because the design process is where most key IT decisions get made. The Architect must take a certain level of responsibility for the outcomes associated with their work - just as brick and mortar architects do. If a client building a Summer house on the beach demands that the structure be built atop sand without concrete or wooden supports, the Architect must let them know the house will likely suffer a structural failure shortly after completion (if not before).

Rule 4 - Architects are problem solvers. Anyone working as an architect who deliberately avoids facing and resolving the tough issues is unlikely to achieve any sort of measurable project success.

Rule 5 - Architects must be able to communicate with the organization they are serving. This applies both to having personal effective communication skills, but also to the projects themselves. Projects that aren't transparent or collaborative tend to take longer and experience high failure rates.

IT Architects tend to be placed in high-profile, high-pressure roles. We who serve as IT Architects are constantly being judged not only personally but also as a profession. Part of the reason the latter half of the previous statement is true is due to the inconsistencies in outcomes for architecture-related projects.

However, if both Architects and their colleagues used the 5 rules above to define what should be happening, the outcomes for most architecture projects would improve dramatically.

Design requires visualization - effective visualizations can be notation-driven or conceptual (as in the above example) 

Copyright 2014, Stephen Lahanas

#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

Solution Architecture Defined

Solution Architecture is sometimes also referred to as System Architecture or Project Architecture. It differs from Enterprise Architecture both in scope and the level of detail. Generally, Solution Architectures are also more narrowly focused (sometimes on a single system or system component  scope) and are usually more detailed in regards to both implementation and configuration. People often view Enterprise Architecture as more strategic and Solution Architecture as more tactical in nature, but in real life this boundary is often blurred.

Solution Architecture is also much less agnostic in nature - in other words, it is more likely that Solution Architecture will contain a great deal of product or specification detail. If we view EA as more Conceptual or Logical in nature - Solution Architecture falls somewhere between Logical and Physical description.

This illustration represents an example of Solution Architecture...

Architectures working at the solution level might have to deal with only one major technology (lets say, PeopleSoft, which in itself is somewhat complex) or as many as a dozen. The context of the work is the boundary of the solution. If the solution or project is focused on securing PII customer data the scope may include all the databases that hold such information, an ESB tool for data movement and an identity management suite for authentication and authorization.

There is a wide diversity of opinion in regards to how Solution Architecture should be practiced or scoped. There is also a relative lack of industry guidance as to how organizations ought to align Solution Architecture with Enterprise Architecture. We will explore these issues in greater depth in future posts.

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Ten Skills IT Architects Should Possess

IT Architects are people who have the ability to engineer and design solutions across the architecture stack and across diverse technologies. While many architecture roles are more specific and require expert knowledge of one or several particular aspects of a larger enterprise environment, architects who intend to work across a broader range of projects need to possess a common set of foundational skills. The top 10 foundational skill sets for IT architectures are as follows:

1. Data Modeling - Data modeling and Data Flow Diagrams are an excellent starting point for understanding IT design principles and issues. The data of a system defines that system and the data flow is essentially a parallel for most business process.  More importantly however, the process of working with stakeholders , experts and users to define Data entities, elements and schemas as well as the data flows provides an excellent view into how Architects perform many of their most important duties.
2. Understanding of Frameworks - Architecture Frameworks (such as TOGAF, DoDAF, FEAF, Zachman, etc.) are essentially giant meta-models or representations of an enterprise environment.  The framework is the template, based upon industry wide expectations and standards from which you can build customized views of your own instantiated enterprise.  Not all architects are expected to use Frameworks, however exploring them provides a great deal of insight into the practice of architecture. Frameworks also do a job of helping to highlight the key challenges or problem sets facing most enterprises.
3. Ability to utilize a variety of design tools - A good architect is never limited to one toolset. There are literally dozens of design and architecture related tools out there and they constantly evolve and continue to proliferate.  Most of these tools however share a set of common functions - it is those functions (such as the ability to model data or design in UML) that are critical.
4. Knowledge of UML - Unified Modeling Language was developed to facilitate software design by providing common notation and diagrammatic views for various types of design issues. UML (and variations of it) have proven to be more flexible than that though and support a wide variety of systems engineering tasks. Getting to know UML will come in handy in virtually all types of architecture projects.
5. Requirements Analysis and Management - This is a skill not always associated with architects, but in fact it is critical to all other architecture tasks. There are tools, techniques and processes associated with effective requirements management (viewed both from traditional and Agile perspectives) that every architect ought to become familiar with. This is a topic we will explore in greater depth in the Dice.com IT Architecture talent community.
6. The ability to visualize complex issues - Most good architects learn to take advantage of "visual shorthand" techniques. This can take the form of standard notations like UML but often involves the ability to create non-standard visual representations. Why is this important? Because IT is a field that rewards brevity; a place of acronyms and pragmatic innovation. If we can see it - we can build it...
7. The ability to communicate across communities - The IT industry is composed of a vast number of subcultures or communities. In order for solutions to succeed, someone needs to be able to bridge those communities. Many people think this is the role of a program manager and sometimes it is. More often than not though it is the architect - a person who must by the nature of his or her job, work at both the high level and detail level across those communities to solve problems.
8. The ability to understand boundaries - This skill may sound a bit strange but is in fact one of the most important ones an architect will ever develop. The reason why this is important is that too often architects take their responsibility as solution designer beyond what it truly represents. The organization and not the architect is the entity truly responsible for the solution. The architect cannot make up for issues that extend beyond their power to control, yet some architects attempt to take on "non-assigned" roles and responsibilities in order to realize their vision. Understanding the boundaries of the architect's role will lead to more successful projects and a more healthy working experience.
9. Analytic problem solving - Architects must use both sides of their brain. I know it sounds a bit painful, but that's one of the reasons architects are able to do what they do. Architects use their Left Brains to apply scientific reason and methodological exactness.
10. Creative problem-solving - On the other hand, Architects also rely heavily on intuition and creative problem solving. This is especially important on projects and in domains where relatively new problems and technologies are being tackled. Knowing when to apply intuition and when to apply rigorous methodology is something architects learn over time. When both sides of the brain can work together, the results tend to improve. 

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

Introduction to the IT Architecture Journal

IT Architecture is a relatively new discipline and represents a cross-cutting community of practice. By that we mean Architecture is not necessarily technology-specific but can be applied to most any technical solution lifecycle. Even where or when architecture does become technology-specific, say for example specific to a particular product or to a set of unique technical standards, the methodology for how architecture tasks are managed can remain largely the same.

This Blog is titled "IT Architecture Journal" precisely because it is worth emphasizing how standard architecture best practices can be applied in any of the typical architecture engagements you are likely to find yourself in.  While many architects may spend their entire careers focused in just one sub-domain of IT Architecture, there is much that can be learned and applied by examining how other architects face similar challenges utilizing different technology stacks. The mind map below illustrates a fairly simplified perspective of how the various types of IT architecture might be classified.  This may not seem simplified but let's take a closer look within one sub-domain listed below - Data Architecture - to see what it's actually comprised of:

• Data Modeling
• Big Data Architecture
• Content & Document Management Architecture
• Knowledge Management Architecture
• Business Intelligence Architecture
• Data Storage Architecture

And of course, a Data Architect might in fact be a SQL Server Architect, an Oracle Architect, a Cognos or Business Objects Architect, a DB2 or legacy DBMS Architect and so on. The common thread for all of these would be the ability to design SQL, build database schemas and do Entity-Relationship Diagrams or ERDs. The larger thread then connecting those data-related capabilities to holistic solutions would be integration within a Solution Development Lifecycle.

IT Architects are typically people who enjoy taking on greater levels of responsibility in solution design and delivery and who aren't easily daunted by complexity. Architects must be able to juggle multiple perspectives and remain cognizant of solution inter-relationships, dependencies as well as the downstream implications of design choices before they're made.  Sometimes IT Architects are viewed as a jack of all trades yet master of none," but this isn't quite fair - because there is in fact a trade that we do master - the ability to Architect solutions.

The IT Architecture Journal will focus on the skills, tools and best practices you'll need to in order to function as an architect. We will provide numerous real-world case studies to highlight key concepts in context. We will, by necessity, delve into a variety of diverse technologies in order to illustrate how architecture techniques can be used to improve outcomes.

copyright 2014, Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More