Authored by Bernard Baillargeon
TOGAF ® and EACOE Certified Enterprise Architect
Email: [email protected]
Enterprise Architecture (EA) represents the drivers and blueprints of all enterprise business concerns, including those of Information Technology (IT). Enterprise Architecture places emphasis upon a consistent understanding of the Business’ problem domains, goals, opportunities, and priority solutions, for all business functions, in human consumable terms and models. IT architectures should neither direct, nor constrain Enterprise Architecture; true Enterprise Architecture actually governs the direction of IT architectures.
Enterprise Architecture Frameworks and Methodologies should provide:
The Open Group Architecture Framework (TOGAF ®) and its Architecture Development Method (ADM) is influenced by, and focused on, Information Technology problem and solution spaces. TOGAF and ADM suggest business’ guidance and impact by embedding ‘business architecture’ as a peer of the IT oriented domains of application, information and technology architectures, possibly eroding the true guidance and influence that must be granted to the business’ intent. While TOGAF presents Business Architecture (BA) as a prerequisite to IT architecture, the subsequent method and phases do not reflect a direct dependency upon BA as one – there is limited artifact traceability; TOGAF and ADM inputs and process refer to composite documents rather than specific items defined within or listed as outputs or suggested outputs of the Business Architecture, such as the catalogs. This masks the traceability behind a composite, where such independence disengages the IT architectures from the directing influence of the Business’ intent, thus Business Architecture within the ADM cycle is actually a lesser peer. TOGAF and ADM may be considered an Enterprise IT (EIT) Architecture method and framework; EIT Architecture is not Enterprise Architecture.
The Open Group Architecture Framework (TOGAF) and its Architecture Development Method (ADM) inherited its baseline content (circa 1995); this baseline was provided to The Open Group by the US Department of Defense (through their Technical Architecture Framework for Information Management, the TAFIM). Additionally, various government agencies have been engaged in TOGAF ADM evolution intermittently since its transition to The Open Group. The evolution since that original baseline has been driven by IT focused organizations, and represents the modeling and methodology based upon complex, composite IT models and IT-oriented models, foregoing the architectural foundation models that would enable a concise understanding of the contributing parts of these complex models. The ADM has added ‘capability-based planning’ as an option to facilitate a business-driven and business-led strategy; this option still does not require the development of architectural models.
The Enterprise Architecture Center Of Excellence (EACOE) framework and methodology focus is on developing the architectural understanding of the entire organization, fully encompassing the scope of Enterprise Architecture. EACOE records, in human consumable artifacts, the discovered unique values of the business with respect to a single frame of reference, the Enterprise Framework, which is an “elaboration” of the work of John Zachman. EACOE believes it is imperative and fundamental to define the architectural elements of the enterprise before attempting to develop complex implementation models, or to envision solutions, without first understanding these architecture elements.
The focus of the Enterprise Architecture Center Of Excellence (EACOE) methodology and its framework, The Enterprise Framework, represents the business as-is and desired interim and future states as they impact all areas of the business’ endeavors, and presents cross-business initiatives to attain these envisioned futures. EACOE emphasizes developing and presenting business-aligned initiatives that drive the enterprise – not just IT – to its “desired” business-goal aligned state. The EACOE-developed models define the business initiatives in a human-consumable format – the emphasis is business understanding first, then technology transformations. EACOE’s The Enterprise Framework defines this understanding and transformation, and guides the EACOE Quick Start Enterprise Architecture Methodology. EACOE recognizes there is not one set of representations serving all stakeholders. There are multiple sets of representations: these five strata of “reification” – how humans treat abstract things as though they were real and tangible objects – are the five strata reflected in The Enterprise Framework.
EACOE defines a Business Initiative as an integrated composite of goals, processes, materials or data, roles, locations, and events that are organized to drive a company’s strategies to a specific desired outcome.
TOGAF ADM presents to the business many Information Technology models from which the enterprise architects select models they believe will be useful, and IT projects derived from those models. TOGAF ADM (inclusive of version 9.1) does not consider business drivers, goals and objectives to be “core” to their content meta-model. While phase A Vision and phase B Business Architecture list the goals, business drivers and objectives as inputs, the meta-model presents these as an extension. This extension to include business focus elements belies the true IT core of the ADM. TOGAF does provide “empty” templates of ‘catalogs’, one being “Driver/Goal/Objective”, yet the ADM Content Meta Model which the ADM navigates and references inextricably, considers the “Driver/Goal/Objective” element not as core, but as an extension. The TOGAF ADM training and website do not provide meaningful, completed examples of these catalogs, nor is any guidance provided on how to achieve a useful consistent set of models using these templates; they are simply offered as a download of empty template files. TOGAF’s Business Architecture Phase B suggests supporting diagrams, such as functional decomposition and organizational decomposition diagrams; architecture is about classification, not decomposition – a fundamental issue; decomposition is an IT or implementation oriented tool to break complex items into contributing implementation parts. Classification is not about parts, it is about “types-of”, and is an understanding tool that must be in place before the complex items can be intelligently combined into diagrams or assessed.
TOGAF architectural phases build upon a ‘Vision’ phase (A), in which TOGAF suggests that practitioners use the systems-requirement process of “business scenario” as the vision foundation. This is fine if the problem to be solved is clear and well defined, and if it really is an IT system needed as the solution, but it doesn’t help to discover or refine and define the full enterprise problem space: What are the many areas of improvement, the many hot spots that the enterprise can address to improve its abilities and state of health? The “business scenario” essentially starts with a directed and assumptive “build this IT solution” mentality, and the traceability is only to this assumed scenario – there are no prior, traceable architectural elements to draw upon, the Vision phase is the start of TOGAF’s approach to define the architecture.
EACOE starts “far to the left” of this point in time in the strategy timeline, meaning that the business opportunity or issue is represented without making an assumption that the solution has to be or actually is technology based – in fact the resulting EACOE initiatives may well offer sets of “business scenarios” that IT might choose to drive through an IT – TOGAF cycle. EACOE builds up the actual architectural elements, models important relationships among them – all traceable to authoritative, verifiable enterprise directives and intent statements – and the discovered realities this unveils helps strategists to “see” the problems, to “see” if there is a solution that must be, should be, or could be pursued. While some of the realized and prioritized EACOE initiatives may lead to IT and perhaps TOGAF or other managed technology implementations, many other initiatives may be high level business value initiatives outside of IT and integrating across multiple business functions.
EACOE Initiatives are one of the key differentiators of its methodology and address cross-business concerns, consistently and equitably prioritized to the Business’ future state intent. The emphasis is to do things of greatest value to the business – what the business needs to be able to ‘see’ and achieve from an analysis of their Enterprise Architecture. EACOE methodology yields to the business a future state series of business goal-prioritized strategic initiatives and a roadmap from the existing state to the desired state. Furthermore, within each initiative, the business will find multiple candidate projects the enterprise architects discovered as they investigated, represented, modeled, and analyzed the discovered and rationalized business artifacts.
EACOE methodology further assesses each initiative and project for additional executive decision points. Enterprise Architects may perform risk analyses over these initiatives and projects for cost, existing project and operational impacts, market gaps or exposure, security, global data influences, and other key issues to assist executives as they select and finalize their next planning phase.
TOGAF ADM presents a non-directed selection of IT models and methods each architect needs to assess, select, and then modify to their organization before beginning any architecture efforts. TOGAF ADM does not provide guidance on how to select these models, how to modify the methods or how to tailor the models and methods to the organization. Advanced architects may be able to assess, select and prepare these models, know the methods they need to apply and how to tailor the various parts to the organization, but advanced architects are a small subset of the architects who need to be able to ‘get their efforts rolling.’ The most important concept for the business is likely to be its goals the business is trying to achieve, yet goals are not considered core to TOGAF ADM. TOGAF does provide to its members two files that contain templates that describe several ADM phase artifacts and document deliverables, generally as very simple, empty skeleton outlines or grids. Furthermore, TOGAF Phase B lists the fundamental architectural lists, the ‘catalogs’, as ‘should be considered for development’. Simply listing a catalog as ‘should be considered for development’ does not measure up to considering something as an essential component. The ADM content meta-model explicitly states that the goals are an extension (motivation extension), that they are not part of the core. Furthermore and more importantly, is the issue of traceability and agility. Something should be either in or out – if it is in, we should say so, and show how it contributes to the overall Enterprise Architecture. In “real architecture”, there are only facts, not opinions or options.
TOGAF does not provide tools beyond the template artifacts and deliverables; automated tooling of any EA efforts is left to relevant vendors which sell tools to support various models and methods as they see fit. These tools are IT architect facing, not business facing.
EACOE provides explicit methods, tools, and directed startup sets of fully contained and human consumable artifacts, to quickly establish a working, productive Enterprise Architecture foundation.
Enterprise Architecture is a new experience for many businesses, especially if the business had attempted to use IT methods alone to define their business. EACOE offers – based on numerous Enterprise Architecture engagements and experience tracing back to efforts begun in 1972 – explicit methods for architects to apply, and specific tools for architects and business interests to use in building, analyzing, and moving their enterprise and enterprise architecture forward to the business goal-aligned desired states.
Each aspect within The Enterprise Framework and Quick Start ™ methodology conveys its content to business decision makers as consistent, business useable and understandable architectural models, described using the business decision makers’ terminology and representations, “in their language.” EACOE refers to this quality as “being human consumable”. This focus helps Enterprise Architects to keep modeling focused on its business owners, not applications, systems, or existing vendor contracts. EACOE’s Quick Start methodology offers a set of fully contained, directed “start up next Monday morning” Architecture Models and Implementation Models with “macro-enhanced”, concise templates to guide enterprise architects to build this common structure. The Quick Start Methodology provides full transformations from business understanding through implementation, providing full and complete traceability from business understanding to system implementation (if desired). The methodology fully emphasizes and supports the required transformations, traceability, and diagrammatic representations to convey in business language the intent of the enterprise.
Common definition structure helps architects and business users of Architecture Models get into a “rhythm of recognition” where the proper descriptive form becomes the expected form, easing the recognition of missing key elements. This is an important achievement when classifying the multitude of items businesses will define and classify, leading to consistently defined Goals, Processes, Materials (which includes information about items of interest to the business), Roles, Locations, and Events. Having consistent definition structure also propels the quick and successful development of the more complex, implementation-oriented relationship models of composite business objects – which EACOE calls Implementation Models, and improves model understanding and business executives’ ability to quickly assess business initiatives.
TOGAF ADM states that it works with multiple frameworks, and with multiple methodologies.
No combination of true frameworks and methodologies has been identified, outside of this TOGAF declaration, in any profession we are aware of, where a methodology can “serve” multiple frameworks. The ADM does have a complex “content meta-model” as part of the TOGAF Architecture Content Framework, which TOGAF considers similar to the efforts of John Zachman and his framework. The content meta-model is where TOGAF declares core items interspersed with those that are considered non-core extensions, including the ‘motivation extension’, as an example, if the organization might be interested in Goals. A practitioner with a clear understanding of John Zachman’s work will question this comparison of this complex, data-entity relationship diagram content meta-model to John Zachman’s concise foundational framework, and will find probably find it difficult to understand a useful relationship between the two.
The TOGAF ADM states that its ‘framework’ – as defined by the content meta-model – is a fully usable tool; I suggest this to not be the case for Enterprise Architecture. The TOGAF 9 specification states:
“The content framework provided here is intended to allow TOGAF to be used as a stand-alone framework for architecture within an enterprise. However, other content frameworks exist (such as the Zachman Framework) and it is anticipated that some enterprises may opt to use an external framework in conjunction with TOGAF. In these cases, the content framework provides a useful reference and starting point for TOGAF content to be mapped to other frameworks.” -TOGAF 9.1
First, to be accurate, I believe TOGAF could be more correct if the statement were constrained to IT: “…used as a stand-alone framework for IT architecture within an enterprise,” I find TOGAF to not address Enterprise Architecture fundamentals well.
Neither do I recognize such a complex model as the ADM content meta-model as a useful tool to map to architectural, singular element models that form the foundation of an Enterprise Architecture; this is a cart-before-the-horse assertion. An enterprise framework, the single frame of reference, is not a swappable item, in my opinion; there is one framework within any area of study in human knowledge, and John A. Zachman’s foundational work still remains the single best representation of the reification that people use to drive abstract ideas into real, concrete instances of those ideas. Map the ADM into John Zachman’s work, or The EACOE Enterprise Framework, and you will see a significant amount of redundancy (some Framework cells are “addressed” 17 times or so within the ADM) showing that the ADM is not based on an agile non-redundant framework/architectural platform – it isn’t mutually exclusive, and collectively exhaustive in its representation.
With respect to other mappings, TOGAF presents a “mixed” message, presenting methodologies, standards, libraries, tools, and frameworks, as ‘frameworks’ that can be mapped to TOGAF ADM:
“In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP.” – TOGAF 9.1
TOGAF has several whitepapers that discuss some of these; each comparison is IT oriented and does not offer enterprise architecture assessment; most pre-date the TOGAF V9 wherein ‘enterprise’ had been ‘added’ to the ADM.
My assessment of the ADM is that it is developed with the content meta-model in mind, and it is focused on IT. The content meta-model is central to the definition of the ADM, and neither provides for, nor informs the required enterprise architectural models. The content meta-model is an IT core data-entity-relationship diagram of significant complexity and cannot be used to derive alignment to a true enterprise architecture frame of reference. When viewed, it is clearly “implementation”, and not “architecture”. I consider that there is only one reference (one ‘content framework’) in this problem space; that is John Zachman’s framework and its elaborations – such as EACOE’s The Enterprise Framework.
EACOE recognizes and emphasizes the fact there is just one “Frame of Reference,” The Enterprise Framework™, as an approach to “Business Problem Solving” or “Business Strategic Thinking,” as the one consistent representational and thinking tool for this area of human study. This one frame of reference parallels the consistency required for every known professional profession (medicine, music, chemistry, language, etc.). The EACOE methodology is set to build upon this singular frame of reference, and helps ensure the practicing architect has the methods and tools to apply their work, and to achieve an explicit and clear statement of their architectures. This keeps the models consistent, and helps simplify the frame of understanding needed by the business.
The Enterprise Framework is a non-arbitrary frame of reference that reflects how humans approach problem solving and move conceptual solutions forward to a realized, implemented reality. As such, there cannot be “versions” of the frame of reference; it exists, and always has existed; Einstein and Hawking didn’t release Time v2.0 and Time v4.5 – their contributions advanced human understanding of time itself. They did not create a new version of time.
Content and scope of the frame of reference is not up for a popularity vote: the content is correct within the field of study or it is not. There is no changing a frame of reference to bow to a consensus. A committee of hundreds who are uncomfortable with the constraints of the field of study cannot vote to change what is correct with respect to the field of study, or to redefine what that field of study is, to conform to their desires or to their businesses’ advantage. We cannot change the periodic table of the elements in chemistry to make gold a noble gas; it is what it is, a transition metal.
Methodologies, of course, can evolve over time, as experiences accumulate. I suggest that TOGAF is not an enterprise framework, even though The Open Group asserts this, nor is it a methodology; however the ADM is the TOGAF methodology, but ADM is not a framework; therefore “versioning” TOGAF ADM as “V9.1” may make sense, while simply “TOGAF 9.1” does not. Considering TOGAF without the ADM is difficult to assign value to, with respect to the practice of architecture.
TOGAF defines some architecture terms, seventy to eighty in its introduction section, others in several disperse locations. Many important critical definitions are deferred to IT standards, with multiple non-related versions presented, and many important concepts are not defined at all. The content meta-model of the TOGAF Architecture Content Framework contains 41 entities, 180 attributes, and 160 relationships presented in an IT logical data-entity-relationship diagram to represent a data centric definition of the ‘enterprise architecture’ concept; we suggest that few business people will even look at or beyond this type of complex representation. TOGAF defines briefly each entity and attribute in a table following the diagram.
In this attribute table, TOGAF declares a goal as
“A high-level statement of intent or direction for an organization…”
“… Typically used to measure success of an organization.”
TOGAF does describe in another section how to define goals by referring to SMART characteristics of Specific, Measurable, Actionable, Realistic, and Time-bound. Again this is suggested, but no strategies to arrive at these characteristics.
EACOE suggests clarity of intent and purpose is paramount in achieving business goals and provides guidance and templates to ensure structured, consistent and concise definitions of architecture elements. EACOE also emphasizes an enterprise level normative glossary to enable business terms, key phrases and acronyms have a single point of authority for business communication and terminology understanding. EACOE promotes using specific templates; as an example, the EACOE Goal template embeds the “SMART” characteristics in a repeatable, consistent fashion that enables all to see immediately where goal definitions need attention to address missing items. Each EACOE Goal, for the Goal model, is defined consistently to meet this template:
Goal Name strives to strategic description, resulting in business value, and will be measured by measurements, by no later than timeframe.
Each element of The Enterprise Framework is fully defined in the Enterprise Framework Practitioner’s Guide.
TOGAF offers complex IT models relating many different things – not architecture models – for architects to select from. Architects must select which TOGAF models to utilize as none are proposed as an experientially good starting set. While such complex IT models might work to effectively represent the current understanding – within the current context of a constrained or well-known domain – this compound composite model can neither articulately represent the important atomic business items, nor those items’ classification within their like-peer representations. TOGAF does refer to some ‘lists’ (catalogs) but they do not reflect these aspects of definition, classification, and leverage across the enterprise. As there is not an atomic set of architectural models promoted as the foundation, none of these varied complex models can be presented as a single source of authority and definition.
TOGAF lists several IT-oriented models as suggestions to the Business architects when determining what they should model. These are meant to extend the Phase (A) Vision business scenarios – a technique to discover and document business system requirements, and include activity models – suggesting the use of IDEF (Integrated Computer Aided Manufacturing (ICAM) DEFinition) modeling technique or The Object Management Group (OMG) Business Process Modeling Notation (BPMN), class diagrams, use case models, node connectivity diagrams, and information exchange matrix. While activity/business process models and use case models can be developed without explicit IT orientation, they usually do so, and are always complex models.
EACOE considers Business Architecture quite differently than does The Open Group, which is detailed in a separate discussion. Regardless, the IT models presented as “business models” clearly show information technology thinking that TOGAF ADM embeds. The ADM discussion within the Business Architecture phase does not provide business models, other than the aforementioned list of ‘to be considered for development’ catalogs, and shows no business level, architectural model techniques. Their examples are IT and complex models.
EACOE stresses two distinct model sets –
Engineering ‘design’ models – which focus on the atomic elements, are different than Manufacturing ‘build’ models – which focus on composites of these engineered elements.
While executives might assume their business team and supporting technologists understand and promote this clarity of purpose in modeling the business future state, it is often missing in existing architectures and Enterprise Architecture practices. This clear separation of modeling focus is very important to enable true understanding of the business and modeled representations. These two distinct, yet tightly related and coupled sets of models are consistent with all know representations of “complex things” in professions outside of information technology. We strongly suggest enterprises and their technology implementations will require these same two sets of models and representations.
EACOE Architecture Models contain ontological representations classifying items of interest to the business. Architects define each of these items using a simple yet detailed template to correctly classify the item with relation to its peers. Each business aspect of strategic thinking represented in the Enterprise Framework has a template and ontology modeled as an Architecture Model. These models become a definitive single source, a controllable authority, and are highly reusable and very effective at quickly promulgating updates across the architecture.
Architecture Models promote clear and consistent communication between business participants, technology participants, and business to technologist communications.
EACOE Implementation Models build upon Architecture Models by presenting the most relevant relationships between items of the Architecture Models in a prescribed, directed set of annotated models. Architects can always develop more complex models and additional relationships; though EACOE realizes a focused set of straightforward models provide high value relationships that efficiently and effectively present, to business owners, the key discoveries that propel their strategic plans. Further progress to build out additional models is a good candidate parallel activity in subsequent iterations of the EACOE strategic initiative “evergreening” cycle.
EACOE suggests significant time be spent on modeling – however, the only end is not models – the end is a series of business aligned initiatives that move the organization to its desired state, derived from these models.
TOGAF ADM holds a perspective of four architecture domains as representing enterprise architecture – Business, Application, Information, and Technology (most notably based on the work of Stephen Spewak’s “BAIT” model) which TOGAF leaders acknowledge as an “IT stack”. Each domain stands on its own for its own purposes, and does not transform its understanding into any of the other domains; each must be interpreted within the other. The ADM cycle visually infers or asserts that the Application and Data architectures are derived from the business architecture, and the technology architecture from these two; this is a natural inference from the circular presentation and asserted “phase sequences,” however the ADM definition of each of these architectures’ and phases’ inputs shows no such waterfall or cyclic feed, no dependency, nor acknowledgement of prior phase models.
Such a heavy IT focus misses significant business opportunity in both problem and solution domains. Architects must map from each domain to the other without guiding transformations, and the resultant mapping may not be consistent without the guiding transformation.
EACOE’s Enterprise Framework assists in discovering value in the transformations from model to model. There are different models and transformations between them – not “decompositions” of details or mappings – to understand for each aspect of the business. A single model does not suffice.
Each of the six aspect models across the Enterprise Framework, therefore, holds a relationship to the models of that same aspect. This relationship is a transformation not a mapping. Mappings suggest one-to-one points within each model that restate the concept in a different perspective. The transformation and separation from one modeled level of abstraction to the next is one of the keys to enterprise agility/flexibility – the separation of independent variables, and “binding” to a solution as “late as possible”. Agility and flexibility cannot possibly come from continuing to “hand-craft” solutions smaller or faster – no matter what the methodology or technical solution suggests.
As one example, Materials (data) of interest to the business (one aspect) is transformed from five stratifications of abstraction:
TOGAF seems to begin at the 3rd stratification, or targeting a technology at stratification 4.
In practice, architects build up the breadth and depth of each model in an iterative fashion, and would rarely reach absolute full definition in the first iteration. The intent of the models is to get the important information captured for the area of interest being modeled, to reduce risk through explicit understandings, and clearly communicated in the breadth and depth of detail of greatest value to each business decision maker. The ongoing change within and surrounding the various aspects of the enterprise clearly place a need for prioritization and reason across the organization, with respect to expectations upon and use of the architecture.
TOGAF certification is a test-center administered task of two parts, level 1 and level 2. Each level of the test consists of multiple-choice questions. If a candidate answers 70% of the level 1 ‘statement’ questions correctly, they have passed that level and are certified at level 1. If the candidate further acquires 24 of 40 points on the level 2 “scenario” questions, they have passed and are certified at level 2. Note that level 2 “scenario” questions yield points for all answers except the one explicitly wrong answer; correct answers get full points, and the other 2 “somewhat correct” answers get less than full points. Once you are certified, you are certified in “TOGAF v9 level 1 (or 2)”. There is no experiential component to be proven, maintained, and improved upon. It is somewhat concerning that the passing percentage is as low as it is stated. If the “exam” for a brain surgeon was based on this percentage, I would sure like to know what 30% was wrong.
TOGAF has used IBM’s “IT Architect Certification” (ITAC) as a basis for advanced “experiential” certification, beyond the basic level 1 and level 2 certification, through several of its versions (since 2005). Currently called Open CA, it remains an IT assessment (IT centric) and Open CA is not an enterprise architect certification. TOGAF had been planning a change and focal shift to Open CA, in order to address Enterprise Architecture.
EACOE emphasizes demonstrated and acquired skills, not one passing of a multiple-choice administered test. The emphasis is on recognizing that Enterprise Architecture skills are acquired through practice and experience, beginning in the EACOE Enterprise Architect Certification Workshop itself.
EACOE provides Enterprise Architecture education and certification on the Framework and Methodology described, consisting of the foundational concepts, developing Architecture Models, Implementation Models, and move-ahead business aligned initiatives.
Upon completion of the workshop, participants receive a two year title of “EACOE Certified Enterprise Architect.” Maintaining this Certification, after the initial two year period requires submission of Enterprise Architecture artifacts that are reviewed by EACOE Enterprise Architect Fellows. This approach is consistent with most certifications offered by professional organizations outside of information technology: engineering, medicine, law, accounting, etc.
Progressive levels of EACOE Architect Certifications require advanced levels of experiential work and broadening influence, levels that are granted by EACOE upon explicit presentation of the resultant works and their influence upon the architect’s business.
TOGAF refers indirectly to the architects as “architecture professionals” within the Architecture Capability Framework component, with the set of supporting concepts that underlie the ADM. Most references to those participating in the ADM are referred to as architects, but there is no concise definition of the responsibilities other than statements suggesting “roles and responsibilities should be defined”.
EACOE recognizes, defines and relates to one another the multiple roles within Enterprise Architecture.
EACOE identified and defined these architect roles and their interrelations, to identify where roles likely interact. The types of activities each is involved with are also defined to improve the overall understanding of architect responsibilities across the enterprise. These roles’ scopes of expertise and influence within the Enterprise Framework are shown below:
These roles include:
EACOE recognizes that following each phase of architecture modeling, additional implementation modeling roles are required to produce a complete Enterprise Architecture. Implementation modeling role titles may appear more recognizable, as they have been highly visible as responsible for knitting together the many complex objects of the enterprise into “whole cloth” solutions, often times, unfortunately, without the aid of Architectural Model foundations.
Enterprise Architecture requires both Architecture Models and Implementation Models; thus, there is a unique need for specific implementation modeling roles.
Since there is a much larger number of possible implementation modeling roles than architecture modeling roles (many possible implementation modeling roles have been identified – e.g. Solution Architect, Information Architect, Application Architect, Service Oriented Architect, etc.), EACOE is working to delineate a consistent, effective workable set of roles and scopes for these Implementation Modeling “Architect” roles in a complementary chart and supporting document.
Implementation modelers can assess their specific role’s interactions with architecture modeling roles, set interaction responsibilities, training, and performance expectations to clarify their implementation modeling roles. This sequence of modeling is the key to agility, reuse, reduced time to market of solutions, and flexibility. The difficulty, of course, is that in most organizations, these roles have been defined without a common frame of reference, or without an exact understanding of what is to be produced by each role. This “randomness” is truly an unnecessary waste of resources. Adopting the Enterprise Framework as the reference frame of reference, allows for definitions of any role precisely, and unambiguously.
TOGAF and the ADM present information technology focused solutions, framed upon information technology focused prescriptive scenarios, and complex implementation models, and not developing true architectural elements, as defined herein. A stated strength of TOGAF lies within its large number of contributing members, over 300 IT vendors and IT clients. This strength is however muted by the overt emphasis on IT, and the sheer number needed to gain consensus on matters of importance makes valuable change slow to evolve. The resulting method and interpretation of Enterprise Architecture reflects a heavy IT presentation and flow. The ADM contains valuable guidance for IT project managers, project leaders, and IT architects to heed when addressing IT projects, and following this guidance with adept personnel should present stable deployments. However, it does not, in the author’s opinion, present an architecture or an architecture development approach; it does present a gathered cache of capable IT implementation approaches and advice accumulated over years of IT experience.
EACOE defines an understanding of Enterprise Architecture where architects use business language to develop human consumable and understandable artifacts and define a platform of knowledge, built by comparison and discovery, by investigation and refinement, all initially without specific IT demands, roots or ties. EACOE approaches Enterprise Architecture as first, how to envision and represent the enterprise business, and not as an IT thing, but as a fuller, more human consumable living and changing spectrum of discovery. This approach evolves to a more complete picture of the envisioned ever-changing enterprise as it meets the demands and challenges in the chosen market spaces. Enterprise agility and flexibility result from Enterprise Architecture and its enabled “make to order” technology implementations; enterprise agility and flexibility does not come from “handcrafting” applications and programs smaller and faster.
The intent of this White Paper is to bring a perspective and understanding to those that are interested in these popular Enterprise Architecture approaches. The author, Bernard Baillargeon, is a practicing and certified Enterprise Architect by both EACOE and The Open Group. He can be reached at [email protected].