9 years, 8 months ago

Welcome EA Summit London

Despite threats from the ash cloud, we’ve arrived and successfully kick-off the EA Summit in London this morning.  We’ve got a tremendous agenda lined up that I’m sure people will find the conference enlightening.  I’m especially looking forward to meeting with conference delegates, vendors and colleagues over the next couple of days at the EA […]

The post Welcome EA Summit London appeared first on Brian Burke.

9 years, 8 months ago

Journal Recommendations

Often getting access to a specific scientific journal can be very cumbersome or expensive, unless you have bulk access through an academic or research institution. In the past few weeks I have been looking for journal articles at the intersection of En…

9 years, 8 months ago

What is Enterprise Analysis: does it differ from Enterprise Architecture?

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.

Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:

BABOK v2 Knowledge Area

Activity in Enterprise Analysis

DefinitionEnterprise Architecture (e.g TOGAF 9)Differences, observations
Requirements ElicitationThis describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don’t know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics coveredPhase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed

Business scenarios are a useful technique to articulate an Architecture Vision.

A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution

To build such a Business Scenario, workshops with business users (stakeholders) would be organized

Business Requirements Analysis

This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more).

Business Requirements for future project investments are identified and documented.

They are defined at a high level, and include goals, objectives, and needs are identified

Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).

That document identifies what will be the business solutions in generic terms

The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business.

There are two steps:

1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team

2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity

Enterprise Analysis

Begins after a Business executive team develops strategic plans and goals

This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project’s direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping).

Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project 

Strategic plan development

 Done outside of the Enterprise Architecture process by business people but is a key source of information

Strategic goal development

 This is done outside of the Enterprise Architecture initiative by business people but is a key source of information
 Business Architecture development Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap

Feasibility Studies

 Done during Phase A: Architecture Vision (with a Business Scenario)

Business Case Development

 Done during Phase A: Architecture Vision (with a Business Scenario)

New Project Proposal

 This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
 Selecting and Prioritizing New Projects This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
 Business Opportunities This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions

Launching New Projects

 This is done during Phase F: Migration Planning

Managing Projects for Value

 This is done during Phase F: Migration Planning

Tracking Project Benefits

 Once the project is in production, it is no longer part of the Enterprise Initiative
Solution Assessment and ValidationDetails how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution

Solutions are identified during Phase E.: Opportunities and Solutions.

This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy.

Risk management, dependencies are taken into consideration.

Business Analysis Planning and MonitoringExplains how to decide what you need to do to complete an “analyst effort” (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job doneCovered mostly in the Architecture Vision phase, then in the Business Architecture PhaseStakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints)
Requirements Management and CommunicationDescribes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst’s work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are usedBusiness Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).

SMART techniques are equally used.

Communication plans are defined.


This diagram below is a draft map BABOK® and TOGAF 9; more work is required!




There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.

  • Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people
  • Enterprise Analysis provides the context in which an Enterprise Architecture should be conducted
  • Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.
  • Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: – Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).
  • Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.
  • Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.
  • Enterprise Architecture suggest a Preliminary phase which is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

About Business Analysis Body of Knowledge® (BABOK®)

The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.

BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.


9 years, 9 months ago

Paradoxes in EA and Systems Research

In my ongoing research, I have identified a close link between enterprise architecture/engineering and systems science. P. Harmon, the prominent business process thinker and author of the book Business Process Change (K. Harmon 2007), Hoogervorst (2009), and Dietz et al. (2008) all discuss the influence of systems science and systems thinking on the process management and enterprise engineering disciplines as such, whilst K. Harmon (2005) even stresses the contention that systems thinking is a basic premise for the successful IT/management strategy implementations in today’s organisations. Interestingly, these authors share the same foundations of research: cybernetics and systems thinking as put forward by Norbert Wiener (1948) and Ludwig von Bertalanffy (1969) — and for Dietz and K. Harmon, R. L. Ackoff (1981, 1993).

Obviously, systems science and cybernetics has offered very important contributions to IS research — especially within process management where organisations are better conceived as self-regulating, self-controlling systems rather than Laplacian machines that reason and act only by their internal causal structures. Systems researchers such as Beer, Bertalanffy, Ackoff, and Checkland have all contributed towards making this a mainstream research branch within a multitude of sciences, and it has also found its way to the enterprise engineering. But K. Harmon’s integration of enterprise architecture research and systems thinking is a good example of cybernetics as a research eulogy: we have finally found the magic gemstone that bridges the gap between our IT systems and business operations. 

Unsurprisingly, that wide statement come at the cost of certain ontological premises. In my thesis research, I have made an attempt at systematizing these premises and their ontological influences on enterprise architecture. The criticism might not be unique or new, but at least it is an attempt to put very important research in the broad frames of enterprise architecture. We keep stating that EA is the future meta discipline for the modern enterprise; thus we also need a broad meta framework that is capable of 1) questioning its own foundation and 2) supporting the diverse types of knowledge, processes, and methodologies within an organisation in order to create and sustain innovation. In my next blog entries, I will present these critique points, and hopefully receive some valuable feedback as well. I haven’t been very good at replying to your valuable comments; that is only due to me being busy, and not because of arrogance or ignorance. I will post a follow up very soon. 

Defining Cybernetics
Before I present the initial critique, it is valuable to define what cybernetics really is, and how it relates to systems thinking. Both disciplines are often used interchangeably, but there are, depending on the author, certain differences. 
Systems theory and Norbert Wiener’s theory of cybernetics are closely related (Heylighen 1999). But where systems theory focuses mainly on the structure of systems, cybernetics concerns the function of a system (e.g. what the system does) in relation to other systems. But, as Heylighen puts forward in Principia Cybernetica, both concepts are facets of the same subject and have permeated into a vast amount of sciences from information systems and biology to social sciences (ibid.). To provide a comprehensive analysis of EA and systems thinking, it is thus also necessary to draw in cybernetics.
The word cybernetics stems from the Greek word kybernetes meaning pilot or steersman and was by one its pioneers, Norbert Wiener, defined as the science encompassing “the entire field of control an communication theory, wether in the machine or in the animal.” (Principia Cybernetica: Defining ‘Cybernetics’ – http://www.asc-cybernetics.org/foundations/definitions.htm — accessed on Apr 11 2010). However, that is only one branch of a definitional wilderness, spanning from Bateson’s very rigid explanation of cybernetics as “a branch of mathematics dealing with problems of control, recursiveness, and information” (ibid.) through Humberto Maturana’s very broad definition of cybernetics as “The Art and Science of Human Understanding. (…) Why? The Person that guides the ship, the skipper, acts both on practical know-how and intuition. Thus, the skipper acts both as a scientist and as an artist,” (ibid.) – and finally to Heinz von Foerster’s very cryptic conceptualisation: “Should one name one central concept, a first principle, of cybernetics, it would be circularity.” (Ibid.)
Concluding on the previous analysis of systems thinking within EA, it is tempting to assume that a systems theoretical foundation for EA is less mechanistic and more nuanced in its conceptualisation of knowledge and organisations. But, in my opinion, that assumption is flawed.

Paradox no. 1: The Enterprise is a System v. The Enterprise as a System
Systems science, as put forward by the authors previously mentioned, operates on the basic assumption that an enterprise is a system, and therefore one must frame it as a system in order to manage it efficiently[1]. But this “systemification” of organisation theory is just as reductionistic and mechanistic as orthodox Cartesian thinking: if we invert the implication, we are logically forced to accept the inference that if the subject matter of interest is not a system, it is not an enterprise. Operating from that premise automatically constrains our framing of organisations in another way and thus entails a new systemic reductionism in the EA discipline. There is a fundamental difference between postulating that enterprises carry systemic properties, behave like systems, or should be interpreted or framed as systems, since the conceptualisation here occurs at the epistemological level (how the knowledge about the subject matter is produced), rather than stating that the subject matter inherently is a system in its own right (which thus occurs on the ontological level — this entails that the fundamental nature of reality or reality is essentially constituted by systems). The words ‘is’ or ‘behaves like’ make a very distinct — and crucially important! — difference.
Accordingly, the philosophical underpinnings of the notion that an enterprise is a system – and, as articulated by Bertalanffy, is best framed as a biological system or organism — are questioned by Kast and Rosenzweig (1972): 

“One of the basic contributions of general systems theory was the rejection of the traditional closed-system or mechanistic view of social organizations. But, did general systems theory free us from this constraint only to impose another, less obvious one?” (Kast et al. 1972) 

Here the authors draw in Daniel Katz and Robert Kahn, who criticise the organismic perception of organisations (1966):

“The biological metaphor, with its crude comparisons of the physical parts of the body to the parts of the social system, has been replaced by more subtle, but equally misleading analogies between biological and social functioning. This figurative type of thinking ignores the essential difference between the socially contrived nature of social systems and the physical structure of the machine or the human organism. So as long as writers are committed to a theoretical framework based upon the physical model, they will miss the essential social-psychological facts of the highly variable, loosely articulated character of the social system” (Katz and Kahn, 1966, p. 31, my emphasis)

Both sources clearly underline the problems of the systems (or first order cybernetic) approach to organisations and EA: the baseline assumption that an enterprise is a system and that this system behaves like an organism (rather than like a predictable machine) is fallible and just as reductionistic and mechanistic as the Machine Age thinking introduced by Ackoff (1981).


[1] An example thereof: Dietz writes, “As said before, the basic premise of enterprise engineering is that an enterprise is a designed system” (Dietz et al. 2008, p. 573), and supports that contention by stating: “The most important premise in the notion of Enterprise Engineering is that an enterprise is a designed system instead of an organically growing entity.” (ibid. p. 578) Similarly, K. Harmon equals enterprises and systems by stating that “frameworks and methodologies used in the development of enterprise architecture should, and in time will, more clearly demonstrate that an enterprise is an intelligent complex adaptive system of systems” (K. Harmon 2005 p. 3).

Ackoff 1981: Creating the Corporate Future: Plan or be Planned For — Ackoff, R. L., Wiley, 1981.
Ackoff 1993: Beyond Total Quality Management. High profile lecture. University of Hull, 18 September 1993.
Bertalanffy 1969: Bertalanffy, L. von, General Systems Theory, New York, George Braziller 1969.
Dietz et al. 2008: Enterprise Ontology in Enterprise Engineering — Dietz, J. L. G and Hoogervorst, J. A. P. – Proceedings of the 2008 ACM symposium on Applied computing — ACM.
K. Harmon 2005; , “The “systems” nature of enterprise architecture,” Systems, Man and Cybernetics, 2005 IEEE International Conference on , vol.1, no., pp. 78- 85 Vol. 1, 10-12 Oct. 2005.
P. Harmon 2007: Business Process Change, 2nd edition, Morgan Kaufmann Publishers, 2007. 
Heylighen et al 1999: Principia Cybernetica: What is Cybernetics and Systems Science? – F. Heylighen, C. Joslyn, V. Turchin 1999 – http://pespmc1.vub.ac.be/CYBSWHAT.HTML (Accessed on Apr 3 2010).
Hoogervorst 2009: Enterprise Governance and Enterprise Engineering, J. A. P. Hoogervorst, Springer 2009. 
Kast et al. 1972: General Systems Theory: Applications for Organization and Management – The Aaademy of Management Journal, Vol. 15. , No. 4, General Systems Theory (Dec. 1972) pp. 447-465, Fremont E. Kast and James E. Rosenzweig, publ. by the Academy of Management.
Katz and Kahn 1962: The Social Psychology of Organizations – Katz, Daniel and Robert L. Kahn, New York: John Wiley and Sons, Inc. 1966).
Wiener 1948: 

Cybernetics: Or Control and Communication in the Animal and the Machine. Wiener, N. Paris, France: Librairie Hermann & Cie, and Cambridge, MA: MIT Press.Cambridge, MA: MIT Press.

9 years, 9 months ago

EA Summit Las Vegas – Day Three

We’ve just wrapped up the EA Summit in Las Vegas and it seems to have been a very positive experience for everyone. The Gartner analysts and our case study speakers were very happy with the level of sophistication of the audience – great questions, comments and challenges.  Many attendees had positive comments on both the […]

The post EA Summit Las Vegas – Day Three appeared first on Brian Burke.

9 years, 9 months ago

On Enterprise Taxonomy Completeness

Yet again it is time for an update on my thesis progress. After revising my initial introductory chapter with my supervisor (John Gotze), I decided to revamp the chapter completely and go forward with a more tangible problem: the failure of strategic I…

9 years, 9 months ago

Zachman: Not a Point of Departure for an Enterprise Methodology

I have spent the last few days reviewing the most contemporary Enterprise Architecture (EA) frameworks. As I am trying to establish a common description of the methodology behind EA, my goal is to sketch the intersection of methodological assumptions these framework impose on organisations. However, the analysis is still on a very high level of abstraction as my goal is a cross-framework conceptualisation. Of course, every framework has its own domain of application, knowledge, and assumptions, and the analysis is fully aware of that.

People usually refer to the Zachman Framework when addressing EA’s point of departure. John Zachman published his famous first words on enterprise integration in the IBM Systems Journal publication A Framework for Information Systems Architecture in 1987, and he is still regarded by many academics and practitioners as the father of the discipline itself. In 2009 I even had the pleasure of following John Zachman presenting an updated version of his framework, and it was definitely inspiring and valuable. Besides being the first to propose an important quantum leap in the integration of business and technology, Zachman is also an excellent speaker and entertainer.

However, my analysis does not depart from Zachman’s original writings, and that is with a specific reason. Zachman has continuously emphasised that his framework concerns structure and taxonomy, and in general not process or methodology. The Zachman Framework is specifically focused on representing a static state, taxonomy, or blueprint of an enterprise, but not how the enterprise has grown the architecture over time — no development methodology is prescribed. It is merely a snapshot or slice of the enterprise at a certain point in time. As Zachman puts it: “The Zachman Framework is a schema. […] More specifically the Zachman Framework is an ontology […] The Zachman Framework is not a methodology.” Zachman’s classification structure is very useful for systematically classifying and describing the current state (or future state) or an architecture, but in my opinion he poses some fundamental erroneous assumptions about methodology and ontology — and manages to represent it in a misleading way:

– The definition of an ontology is (according to Wikipedia): “the philosophical study of the nature of being, existence or reality in general, as well as the basic categories of being and their relations.” Let us for a moment assume that it is the second sentence that Zachman focused on when using the word ontology in his writings. Ontology is in the first place quite a big word (or efficient discourse) to use when describing one out of many frameworks, and I agree with Dave Snowden when he postulates that the word taxonomy is a much better concept in the context of enterprises.

– Given that ontology concerns the “basic categories of being and their relations”, Zachman must assume that a being is already in place, and that this being is involved in the creation of the relations. Being assumes a process, the creation of something — taking part in the world — or maybe less dramatic: the organisational field — over time. But if Zachman’s schema only concerns the organisation at a single point in time, how can it truly represent the inherent causality between the objects it claims to classify in an efficient way? A complete description of the objects and their interdependencies within an enterprise must assume a certain level of context within time and space. A snapshot for putting the enterprise in a context is simply not enough. And as ontology assumes both causality and being, Zachman’s framework simply is not an ontology. Similarly, Mendeljev’s periodic table (which Zachman often uses as an powerful analogy to his own concepts) not only describes the static composition of atoms (implies structure), but also how atoms evolve over time (implies process) as they wobble between a stable and unstable state. Again, Zachman’s use of the term ontology is insufficient.

In short: the word ontology is simply too strong a discourse for a classification system, and a snapshot classification is again not sufficient for efficiently describing an organisation without loosing important information. How and why the organisation is in its current state are in my opinion two major prerequisites that need to be determined before we can describe an optimal future state, and the Zachman Framework is in a conscious manner sawing off the branch that its own reality check with methodology sits on.

In my search of enterprise methodologies, I have decided to take GERAM – The Generalised Enterprise Reference Architecture and Methodology — as my point of departure. Peter Bernus, one of the authors behind the framework — presents it as a meta methodology for describing reference architectures: “Potentially, all proposed reference architectures and methodologies could be characterized in GERAM”— whilst emphasising the framework’s ultimate purpose of methodological unification:

“GERAM is intended to facilitate the unification of methods of several disciplines used in the change process, such as methods of industrial engineering, management science, control engineering, communication and information technology, i.e. to allow their combined use, as opposed to segregated application.”

The IFIP-IFAC task force certainly created the first real stepping stones towards a true ontology and methodology for formally characterising and representing an enterprise in context. After all, that requires an inclusion of both structure and process, and these cannot be separated without leaving out important knowledge about the enterprise itself.

9 years, 11 months ago

More than trends

A colleague at Microsoft, J.D.Meier, recently wrote a blog post about the major trends to watch for in 2010. Rather than creating just a new list he’s provided all the source material references which make it ideal to use for personal research and to take a unique filter for your own organization.

What really struck me in reading this was the last section, which is less about trends and really about what each of us needs to consider to be relevant and at our most effective in the coming decade and I’ve repeated it here:

  • Build a firm foundation.  Know Maslow’s hierarchy and prioritize taking care of your basic needs.  Know your “monthly burn” and be mindful of your decisions to support your firm foundation.  The stronger your foundation is, the more you can help yourself and others when they need it most.
  • If it doesn’t help you be your best, cut it out.   This means living your values, and playing to your strengths.  It also means giving your best where you have your best to give, as a person, and as a company.  It’s how your survive, and it’s how you go from surviving to thriving.   Any other way drains you in the long run and you get priced or pushed or competed out of the market.  It’s the sustainable path. 
  • Follow the growth.  Follow your own growth, and follow the growth in the market.  For example, in the tech industry some growth areas are mobile and cloud.  Along these lines, create the growth.
  • Get back to the basics.  Practice the fundamentals.  They work.  Among the chaos, there are always core principles, patterns, and practices that you can bank on.
  • Hone your personal brand.  Make the most of what you’ve got and make sure your differentiation is obvious.  For example, one of my differentiators is “getting results.”
  • Invest in yourself.  Inner-engineering always pays off.
  • It’s your network and what you know.  People sort and sift through people they know.  In a skills-for-hire economy, your network is how you find the opportunities. 
  • Know the cycles of things.  For example, know the Four Stages of Market Maturity, the Technology Adoption Life Cycle, and the Diffusion of Innovations.
  • Lead yourself from the inside out.   Follow your values, play to your strengths, and follow your purpose.  It’s the sustainable path.
  • Learn and respond.  Your ability to learn and respond will drive your best results.  Innovate in your process and your product.
  • Look ahead.  Build your anticipation skills.  Know the system.  Things don’t just happen.  The more you know the system and the ecosystem, the more you can anticipate what’s coming down the line.  Pay attention to market leaders, trend setters, patterns, and cycles.  Everything happens in cycles whether it’s growth or decline.

All too often we have work commitments and development plans that are focused on the near-term, possibly as short as the next quarter. But as we see continuous change becoming the new normal I thought these were fine words to reflect on, and practical steps for how we should think about surviving the long term.


10 years, 5 days ago

Using predictions to think ahead

It’s about this time every year that we begin to be bombarded with the top 10 predictions for just about everything in 2010. About the only thing I believe from the predictions mania is that new technology will take longer to have an impact than we believe and that in many cases we really don’t have a clue just how big the impact will really be.


One of the more interesting of this year’s crop of predictions (for me at least) is represented on the map at this link  although you’ll need a big printer to make it readable or a bit of pan and zoom.


What I like about this is the sheer scope and scale of the map that allows me to see ideas being grouped together and consider the bigger picture if a set of them do happen around the same time – and what our opportunity might be if we’re ready for the situation.


Enterprise Architecture is not just about creating models but also about understanding the potential for change and building the appropriate level of agility into the future architecture to be able to take advantage of it without increasing the cost or risk beyond what could reasonably be expected.

10 years, 1 month ago

Are you a Business Architect or a Business Analyst?

Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.

Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?

Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.

Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.

Expected skills and activitiesBusiness AnalystBusiness ArchitectComments related to TOGAF 9
Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support.xxBoth roles require to be positioned between IT and business.
In particular business processes of a line of business.xThe Business Architect considers the organization’s strategy and less focused in a specific line of business.
Acts as catalyst to implement strategic and tactical change for the business.xxThe Business Architect will focus more on strategic changes.
Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processesxxThe Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM).xx
Performs analysis and documents business processes leading to process change and/or system implementation.xxThe Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM servicesxThe Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services.
Does not have an IT background, but had, instead, a background in quality control.xThe Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop softwarexA Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C.
Analyze and resolve software errors in a timely and accurate fashionxA Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application).
Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture.xThe Business Architect does not contribute to software development. This is done by the Solution Architect.
Leads and validates enterprise system designs across multiple business applications.xThe Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect.
Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solutionxThe Business Architect does not contribute to test plans. This is done probably by the Solution Architect.
Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities.xxIn the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated.
Determining how business policies are implemented in business rules.xxBusiness rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level.
Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective.xxBusiness scenarios would be used to identify business requirements.
Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture.xThe Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture.
Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance.xBusiness Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives.xThe Business Architect works at a strategic level and focus mostly on Strategic Architecture.
Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes.xBusiness Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks.xxRisks have to be identified during both the Architecture vision phase and the development of the solution.
Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks.xThe Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management.xxBoth roles require these skills.
Proven track record for working effectively with technical and business functions.xThe Business Architect must work with other domain’s architects.

My observations are:

Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.

Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.

The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.

Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.

10 years, 2 months ago

The role of the Solution Architect during the implementation

In my previous article I describe the role of the Solution Architect within the TOGAF ADM, mostly acting between phases E to G, with a specific focus on E (Opportunities and Solutions) and F (Migration Planning). This article will cover the role in phase G: Implementation governance.

The objective of that phase is to formulate recommendations for each implementation project, and govern and manage an architecture contract covering the overall system implementation and deployment. In companies where the maturity is high, it would be perfectly acceptable to have the Solution Architect acting in the name of the Enterprise Architecture team and coordinate activities during the phase G.

TOGAF defines objectives during that phase and each of them may be detailed as follows.
To formulate recommendations for each implementation project (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the Development Team:

  • Participates in assessment of solutions needs consistent with the global business strategies
  • Re-analyzes business practices.
  • Provides business analysis and documents process design of system functions and processes as identified in the phase B.
  • Recommends application design within the development team. Supervises and ensures quality delivery of the analysis, design, and build of the hardware, network, and common software platform components of software releases with the development team.
  • Assesses identified technologies from the phase D, and makes sure that solution options are based on the target architecture. Note: He will be directly accountable for the acceptance of technology architecture deliverables by the client.
  • Participates in the planning, development, maintenance, installation, configuration, documentation, training and implementation of new applications/solutions. He is accountable for the documenting requirements (hardware, network, and configuration) captured during the previous ADM phases. He may also develop the engineering documentation.
  • Participates in the development of functional specifications for developers related to modifying functionality, report development, outputs and interfaces.
  • Works with internal customers, external consultants, IT staff and other stakeholders to refine requirements when needed.
  • Leads and participates in developing and facilitating end user workshops for the solution.
  • Supports existing applications within the company’s active portfolio and extends their use where appropriate according to the gap analysis.
  • Coordinates and/or participates in the planning and execution of application testing.

To govern and manage an Architecture Contract covering the overall implementation and deployment process (Source: TOGAF 9)

He identifies if there are any issues between the architecture and the implementation organization.

To perform appropriate governance functions while the solution is being implemented and deployed (Source: TOGAF 9)

He will refer to existing governance best practices such as IT Service Management, Project Management, Risk Management, Security Management, and Audit management (for example).

To ensure conformance with the defined architecture by implementation projects and other projects (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

To ensure that the program of solutions is deployed successfully, as a planned program of work (Source: TOGAF 9)

He will Review ongoing implementation governance and architecture compliance for each building block.

To ensure conformance of the deployed solution with the Target Architecture (Source: TOGAF 9)

He will support the architecture design review using a customized checklist as defined in TOGAF.

To mobilize supporting operations that will underpin the future working lifetime of the deployed solution (Source: TOGAF 9)

The Solution Architect with the Enterprise Architecture team and the IT Operation Team:

  • Helps to monitor and supports the operations architecture of for hardware, network, and common software platforms (including configuration approach, deployment, approach, and monitoring approach).
  • Supports all hardware, network, and common software platforms in Development, Production, and Operations environments. Must be aware of the status of the system in all environments, and must communicate and manage environment related risks and activities.
  • Supports build team by managing configuration of hardware, network, and common software platforms (like Application Servers).
  • Establishes and maintains relationship with key clients with-in client IT organization.
  • Develops and implements plan for increasing level of technical architecture skill in program staff.
  • Ensures consistent implementation of technical components across release activities with the IT Service Management team if it exists (e.g. release manager).
  • Identifies production infrastructure related issues in the production environment with the help of both the Service Desk and the System Management team if they exist. Creates and implements issue resolution plans that have to be escalated to the Enterprise Architecture team.

This diagram is a high level representation of the Solution Architect’s activities interacting with all parties involved in the architecture development and delivery.

This approach where many activities are led by a designated Solution Architect. The alternative being to share the role between several architects from the Enterprise Architecture team.