Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

Job Description for Business Architecture

Job Description for Business Architecture

Rate This
  • Comments 20

As the result of reading some discussions on the responsibilities of Business Architecture, I got to thinking: How to describe the list of prerequisites for Business Architect, and what is the career ladder that I believe a good BA goes through?

I did a quick bing search to see if other folks had attempted to answer this question.  While there are a few job postings on various boards, there are surprisingly few discussions of job skills or a job description.  One notable exception was posted in the summer of 2009 on the BPMI site, but that one is not particularly distinct from Enterprise Architect. (see below)  For this blog post, I started with the posting by Geoff Balmes from the BPMI site, made a few edits to clarify the distinction from Enterprise Architect, and posted it here.   

Qualifications of a Business Architect

Role
The Business Architect analyzes the activities of a particular business unit or line of business and makes recommendations pertaining to the projects that the business unit should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information. This person illustrates the alignment (or lack thereof) between strategic goals and key business decisions regarding products and services; partners and suppliers; organization; capabilities; and key business and IT initiatives. The primary focus of this person’s work includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

Organization
The Business Architect reports into business management and works closely with other business architects, enterprise architects, and counterparts in Information Technology. The Business Architect may have supervisory responsibility, possibly acting as coach and mentor to junior colleagues in a similar or reporting role. In addition, the Business Architect works though others at every level of the organization soliciting strategic imperatives from senior leaders and executives, and supporting business unit managers as they leverage business architecture artifacts to create their business plans. Finally, the Business Architect may provide direct input into the governance cycle for the funding, oversight, and realization of business projects.  In that governance role, the business architect helps to insure that business and IT projects are aligned to support the achievement of key goals, that specific business scenarios are considered and that business value is delivered. 

Responsibilities

  • Develop a business architecture strategy for the business unit based on a situational awareness of various business scenarios and motivations.
  • Apply a structured business architecture approach and methodology for capturing the key views of the business unit in the context of the enterprise.
  • Capture the tactical and strategic business goals that provide traceability through the organization and are mapped to metrics that provide ongoing governance.
  • Describe the primary business functions of the assigned business unit in the context of the enterprise and distinguish between customer-facing, supplier-related, business execution and business management functions.
  • Enumerate, analyze, catalog, and suggest improvements to the strategic, core and support processes of the business unit, as needed, to support strategic and operational goals.  
  • Define the data elements shared between this business unit and other units in the enterprise and the relationships between those data elements and processes, people, systems, and other data elements.
  • Enumerate, analyze, and suggest improvements to the structural relationships of the business.  This requires the creation and maintenance of an ongoing model of roles, capabilities and business units, the decomposition of those business units into subunits, and the interplay between these units in various business processes, materials, people, and systems.

Skills and Qualifications

  • A broad, enterprise-wide view of the business and varying degrees of appreciation for strategy, processes and capabilities, enabling technologies, and governance
  • The ability to recognize structural issues within the organization, functional interdependencies and cross-silo redundancies.  Those issues may exist in role alignment, process gaps and overlaps, and business capability maturity gaps
  • The ability to apply architectural principles, methods, and tools to business challenges
  • The ability to assimilate and correlate disconnected documentation and drawings, and articulate their collective relevance to the organization and to high-priority business issues
  • The ability to visualize and create high-level models (rigorous information-rich diagrams) that can be used in future analysis to extend and mature the business architecture
  • Experience developing and using these high-level models as required to collect, aggregate or disaggregate complex and conflicting information about the business
  • Extensive experience planning and deploying either business or IT initiatives (preference for both)
  • Experience modeling business processes using a variety of tools and techniques (preference for BPMN)
  • Exceptional communication skills and the demonstrable ability to communicate appropriately at all levels of the organization; this includes written and verbal communications as well as visualizations
  • The ability to act as liaison conveying information in suitably accurate models between the business unit and their counterparts within Information Technology.  The scope of this information includes business requirements, data constraints, business rules, models of strategy and motivation, processes, accountabilities, and many other business and IT operational needs 
  • Must be a Team player able to work effectively at all levels of an organization with the ability to influence others to move toward consensus.  Must be highly reliable, trustworthy, honest, and commitment oriented
  • Strong situational analysis and decision making abilities

The Career Ladder of a Business Architect

Describing the career ladder of a business architect is difficult for many reasons.  This is a new field, and the business architects that I know arrived at their career from different directions and are likely on different trajectories.  What I can say is this: becoming successful at business architecture is an extremely useful skill in many aspects of corporate life, and can provide very useful insight and connections into upper echelons of management. 

To become a business architect requires strong business skills.  A degree in business is more than helpful… few business architects will succeed without one, although a decade or more of experience in an industry can make up the difference.  Note that I’m not focusing on consultants who perform a business architecture assignment, but rather on full time employees who would be able to perform this role.  A firm understanding of structural models is the next prerequisite skill and this kind of thinking is often found in people who “think visually.”  Look for creative individuals in accounting, marketing, and information technology who can tend to draw diagrams in their presentations that represent the relationships between concepts, people, processes, or business functions.

Once you have proven successful as a business architect, the next step depends on you.  The obvious next step is to the role of enterprise architect.  To be a successful EA, one should have been successful at one of the key EA roles (Business, Solution, Information, or Technology Architecture) and have a reasonable grasp and appreciation for the other roles.  Not an easy step.

Another direction for the successful Business Architect is into business management.  A BA can see relationships that most mid-level managers have never been trained to look for, and have a rich understanding of how to use that information. 

How a Business Architect is different from an Enterprise Architect

I personally consider an Enterprise Architect as a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect.  In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA.  What this means, in my opinion, is that you should not call yourself an Enterprise Architect unless you have full capability as both a BA and an SA and at least partial capability as an IA.  (No, a course on the Zachman Framework or TOGAF is not sufficient). 

In Zachman terms, an EA has to be able to perform across ALL ROWS AND COLUMNS of the framework.  A Business Architect doesn’t have to extend below row 2 or perhaps 3, while a Solution Architect usually lives in the lower rows.  An Information Architect, at the enterprise level, must be able to run the gamut of a single column of the Zachman framework. 

  • Hi Nick,

    I think you've missed the most obvious entry path: the business analyst. While most business analysts work at the operational or project level, this description is pretty much identical to the business analyst role and qualifications scaled up in terms of possible complexity, scope and risk.

  • With all due respect, Kevin, I did not forget the business analyst.  I said "Look for creative individuals in accounting, marketing, and information technology "

    Last time I checked, many business analysts fall into that description.  (Not all, of course.  Not all business analysts will find the Business Architect path appealing or successful).

    You are seeing a lot more alignment between business architect and business analyst than I am.  Perhaps in your organization, the business analyst role has been fulfilling some of the demand that the business architect is supposed to fill.  Normally, there is quite a gap.  

    If you find a person whose job is to work on a project, describing the business processes, or modeling changes to business processes, or eliciting business requirements, or working to ensure the success of "user acceptance testing," then you have NOT found a business architect.  A business architect has NONE of these responsibilities.

  • Nick,

    I'm not asserting that all business analysts are going to make effective business architects. However, saying that the difference is that the business architect doesn't have some of the responsibilities of the business analyst is not a convincing argument that they are distinct. ;-) A better question is what skills does a business architect have that a business analyst doesn't need?

    I'm coming at this from years of work with IIBA, including extensive surveys of the BA community, during which we have identified the characteristics, skills, and competencies associated with people who are effective as business analysts, and those skills are the ones you identify above as needed for a business architect.

    From my perspective, the only differences in the role description that I see here and elsewhere are that business architects handle a broader scope (departmental or enterprise as opposed to project or initiative) and deal with greater complexity and risk than your typical business analyst. When I look at your list, and scale those things DOWN to the project level, every one of them is something that a skilled business analyst should be able to do.

    In short, how is a business architect not a business analyst working on larger and more complex problems?

  • Hi Kevin,

    I'm not sure what the argument is.  A business architect is a role that MAY come from a business analyst.  We've established that.  They may also come from many other areas.

    Are you suggesting that the role of business architect does not exist because it is another name for a business analyst?

    You know that a draftsman and a renouned building architect both need the same skills, but in different quantities.  

  • Hi Kevin,

    I'm going to add a bit of experience to this mix.  I just came out of a meeting where the difference between a business analyst and a business architect was so clear, that it would make your head spin.

    The business customer that I was speaking with was not happy with her business analysts.  Couldn't see what value they were adding at all.  Her business architect, on the other hand... very valuable.

    Of course, that reaction is situation specific, and that's exactly the point.  A business architect plays a different role than a business analyst, at different times, with different people.  That requires substantially different skills.

    The fact that you seem unable to recognize that means that you have not been fortunate enough to work with a talented business architect.  

    It does not mean that a business analyst has the same skills, or would make a good career path, to business architect.  I suppose it is possible, and I leave open the door.  But not enough to call it out.

    In fact, I do not believe that I know ANY business architects who were business analysts in their prior careers.

    --- Nick

  • Hi Malik,

    I just wanted to point out an inconsistency in your description. You state in "How a BA is different from an EA" section that "an EA can perform at an enterprise level, something that is NOT required of either an SA or BA." Your first bullet under Skills and Quals is "A broad, enterprise-wide view of the business and varying degrees of appreciation for strategy, processes and capabilities, enabling technologies, and governance."

    Can you clarify your statements more?

  • Hello Wade,

    I would expect a business architect to be able to see and understand their business area in the context of the enterprise.  In other words, they need to be able to understand enough about the entire enterprise to be able to recognize the influencers, dependencies, and relationships that influence how their organization must function.

    That said, I would not expect a business architect to perform activities on behalf of the entire enterprise, but rather on behalf of a particular area of the business.  The models will drill in on the specific capabilities, processes, artifacts, and relationships within their assigned area of the business and their results will be primarily valuable to business people both within that area of the business and partners (both internal and external) of that line of business.

    Does this help clarify the distinction?  You raise a good point and if I get a chance, I'll update the post to reflect.  Thank you for pointing this out.

    --- Nick

  • Yes. Thanks Nick. I've served in both roles and I was interested in how you distinguished between the two, especially since (in my experience) EA's still are a new role that orgs struggle to define.

    So it's good to have clarity between the functions.

    Cheers!

  • Nice info, you describe this job description very clear, for the time being I will bookmark this post to my favorite social bookmarking. I'll be waiting for the next post. thanks

  • Hi Nick,

    I am curious with the content and would like to establish the following points. This is point 1 questions.

    1. Business Architect's Skills

      a. Business Acumen - understanding business motivation, business operation

      b. Strong Analytic - able to dissect business problem at "40,000" ft and also at the granular details

      c. Strong Problem Solving - able to provide solution with an engineer mind (logical) with an out of the box thinking (creative).

      d. Financial Or Accounting Skill - able to understand the main information flow of the business

      e. Present Business Requirement - translating business strategy to requirements that can be implemented by project(s)

      f. Proficient in Technology - understand technology capabilities and framework

    Can you let me know if I made a good summary of the key skills?

    I do have some more questions. Hope I get your reply soon.

    Cheers

    Gary

  • Hi Gary,

    Nope.  I'd say that your summary is more of a business analyst.  You forgot the key skills of principles application, assimilation of a broad array of information, the creation of models and the use of models to develop decision-making outputs.

    From above:

    --The ability to apply architectural principles, methods, and tools to business challenges

    --The ability to assimilate and correlate disconnected documentation and drawings, and articulate their collective relevance to the organization and to high-priority business issues

    --The ability to visualize and create high-level models (rigorous information-rich diagrams) that can be used in future analysis to extend and mature the business architecture

    --Experience developing and using these high-level models as required to collect, aggregate or disaggregate complex and conflicting information about the business

  • Thanks for you reply Nick.

    I would not be proceeding with my pt 2 set of questions.

    At the same time, I would like to clarify that I did not miss the points you mentioned.

    --The ability to apply architectural principles, methods, and tools to business challenges

    Gary > Under Strong Problem Solving - An engineer apply an engineering principles, method and tools to an engineering challenge, this is only possible with Strong Problem Solving Skill. For an architect - architectural principles, method and tools. To apply the correct principles, methods, tools will require Analytical and Problem Solving skill.

    --The ability to assimilate and correlate disconnected documentation and drawings, and articulate their collective relevance to the organization and to high-priority business issues

    Gary > Under Strong Analytic. Best way to solve a problem is to understand all the dimensions of a problem. The term "40,000 ft" already imply a broad base view of the entire problem (assimilate & correlate disconnected documentation), priority of business issue depend on the granular detail (as in which level of granularity it is subjective.)

    --Experience developing and using these high-level models as required to collect, aggregate or disaggregate complex and conflicting information about the business

    Gary > I do not think experience is a skill. Instead a skill is gain by experience (applying HR principle). Thus the skills here are still Strong Analysis Skill (collating information), Strong Problem Solving (aggregate & disaggregated) and at the same time Strong Translation/Presentation Skill (using the model). You can become more skillful with experience.

    As you mentioned "You know that a draftsman and a renounced building architect both need the same skills, but in different quantities." Thus those missing are just different level of the key skills that I have mentioned.

    “Present Business Requirement - translating business strategy to requirements that can be implemented by project(s)”.  This is not eliciting business requirement and translating into technology solution.  This is look at the business strategy and articulates the business requirement so that a “draftsman” can put it into plan. That is not a Business Analyst Skill.

    An example, the Burj Al Arab was designed base on the business brief “create a building that would become an icon for Dubai rather like Sydney has its Opera House and Egypt has the pyramids." The brief was given by Jumierah International (business), which is thus translate into a blueprint (requirement) and built to specification by the various project(s), different teams handling different part of the construction.  

    Thanks once again for you answers

  • Hi Gary,

    When I was a teenager, I thought I'd make a good gardener.  After all, my father loved to work in his garden and I would occasionally join him.  I figured I knew a bit about how to take care of plants.  My first, and only, gardening job resulting in me being fired after two days.  

    I did not know what I did not know.  This is what Blanchard would call "stage 1" level of maturity.

    I could make all the justifications in the world that my skills, at 15, were the right skills but in the wrong quanitity.  Justifications didn't matter.  I was not qualified for the job and did not know why I was not qualified for the job.  

    In fact, I was SO FAR AWAY from being qualified as a gardener that I couldn't take constructive criticism because the people speaking to me had a basic assumption about the some shared underlying concepts, and I did not share those concepts.  I could not understand *why* I was not qualified.  I couldn't even name the skills I needed but did not have.

    I get applicants like this sometimes... applicants who see a job description and say "that's similar to a job I've had before... I'll apply to that one," without any reasonable level of understanding of what the job actually is or entails.

    This is not my first rodeo.  

    If I ask for demonstrable experience in something, then I'm asking the applicant to explain to me not only *that* he can do something useful, but all of the details of what he did, how it was done, and how it was received by the stakeholders.  Because that is how I can tell the difference between someone who thinks that they are qualified and someone who actually is.

    Regards,

    ---- Nick

  • Hi Nick,

    Agree with your story.

    Therefore a Business Architect (Biz Arch) must have the skills and the experience (which was going to be my second set of questions). How to determine experience (was my third set).

    Experience polish skill, thus make you more skilful, which then enable the person to take on a role that require the person to apply his/her skill at that maturity level. My first set of questions only focuses on Skill not Experience and not the whole role description of a Biz Arch. If you continue to try out gardening and practice it, you will become a gardener. And if you practice with creativity, you become an exceptional gardener.

    What I am doing is assimilating, aggregate and dissection complex and conflicting information (your role description was not structure :P.. so got me curious). There is a mixture of skill and experience under the heading of "Skill & Qualification". HR principles would split competency (level of experience and ability to apply skill) and skills.

    One of the key skill of Biz Arch is presenting of business requirement (business in this case is subjective). In this situation you are the business which present the role of Biz Arch (You are presenting what you consider is the requirement of a Biz Arch). I would be applying HR principles when presenting this requirement, method and tools.

    Hope we are still doing constructive discussion. I am not trying to defeat or find fault on your article. I am just curious.

    Cheers

    Gary

  • Hi Gary,

    I appreciate your comment.  It is true that I mixed the notion of skill with experience because I was looking for "demonstrable skill" or "mature skill."  In other words, if I'm looking for a master gardener, and not just an apprentice, I won't ask about planting techniques.  I want to see pictures of a garden design, the planting, the maintenance, and the result.  

    I want to know that the person has gone the entire gamut and learned from it.  IMHO, any attempt to pull apart the two (skill and experience) leaves hiring managers without the tools that they need to find (and ultimately improve) the right person for the job.

    That said, you are certainly correct in noting that HR folks like to split the two up.  I think it helps with the notion of classifying people according to their particular skill sets.  I don't take much stock in that.  I've hired good people, and I've hired not-so-good people.  "Demonstrable" skills were usually the difference between the two. YMMV

    How to determine experience?  I don't think you do.  When I work in my job at Microsoft, I become good at my job in Microsoft.  I become good for Microsoft and get better at filling my role.  That may, or may not, make me a good fit for an EA job somewhere else.  Therefore, if someone was to look at my experience, they would not be reasonable to say "what is the measure of it," but rather " how applicable are his experiences" to the work that they'd like to see me do at that other place.  

    So I don't measure experience.  I will be honest.  If a very mature EA joins an organization that is not ready, or willing, to become mature at EA, no one is happy.  The person has to have the skills for the job that is there, not the job that "should" be there.   

    --- Nick

Page 1 of 2 (20 items) 12