Skip to main content

Tag: Business Analysis

The Bad Ass BA: “Business Architect”?

FEATURENov1stWhat the heck is a Business Architect? 

I have had the title Business Architect for almost a year now — I’m loving it. With about thirty years’ working experience in software and the last ten years in the role of business analyst, the next step for me was business architecture, but if you asked me a year ago what that meant, I wouldn’t have been able to give you a succinct answer, or tell you the elements of the discipline. It was something about the connotations of the word “architecture” that attracted me. The notion of integrating all the functionality together, having hierarchies of taxonomies in your head, ooh, ooh! But thinking and doing take more than a little effort to link. Sometimes stubborn people like me need a kick in the rear from the universe to get moving. So while I didn’t like getting laid off last year, because as much as I was relieved to be out of there, my pride was hurt, it was time to go and it forced me to recalibrate myself professionally and make the leap.

The trouble was, there was so much conflicting information about the role of the Business Architect. There’s lots of conflicting opinions on the differences in focus between an Enterprise Architect, a Business Architect, an Information Architect and a Process Architect.

Being intuitive and somewhat reckless, when the interview question came up from the Enterprise Architects about what technologies I would recommend, I heard these words coming out of my mouth, “Gentlemen, you shouldn’t be hiring a business architect to advise you on technologies. I may have my opinions, but there are far better qualified people out there for that. I would be bringing you information about business needs and business processes, not on technologies or solutions.” This was a phone screening. There was dead silence on their end of the line. Darn it, Cecilie, you’ve stuck your foot in your mouth again, I thought to myself. Then, I hear, “Okay! Would you tell us about a situation in which…” Whew, they were still talking to me.

I knew I could do the tasks identified in the job description, but I knew I had to get ahead of the professional development curve if I was going to succeed in this role in the long term. After a few months on the job, there was an opportunity to take the equivalent of Business Architecture 101 at a conference, so I signed up for two 1-day seminars. One of the seminars was just okay. The second one was mind blowing — one of those experiences where every synapse in your brain is pulsating and your neural matter hurts for days afterwards because new neural pathways are forming, and old, deep patterns that have never been challenged before have been cauterized out. I walked around for a week after that seminar like a grinning fool.

I needed definitions and I got ‘em. After keeping these definitions in the back of my mind for the past six months, I’m ready to share — they are valid and I hope you find them useful for your career development and for your endeavors in the Enterprise Analysis knowledge area of the Business Analysis Body of Knowledge.

What is Business Architecture?

First, a business architecture is not a business function/process model. Most business process models show an inventory of processes, but not an integrated model of the information used by those processes. Most business function/process models do not show the customer/consumer/end user or how that customer perceives the touch-points between the business processes and functions.

Business Architecture occurs when you integrate two or three or more different core cross-functional business processes in an engineering type of model, and as a result, make things more clean and efficient. This model is the beginning of an enterprise business architecture. The definition I use is a model of an enterprise (single company or industry) that shows the integration points of all the information that enables the enterprise to function. The model shows information sources, destinations and transformations.

Furthermore, for a single company, a business architecture is just one element of an integrated enterprise architecture. The integrated enterprise architecture includes business, technology, security and organizational architectural components to create a complete model. In addition to all the modeling techniques I have used as a business analyst, I have added capabilities, value streams and value chains to my bag of modeling techniques.

No discipline is without its controversies and the usefulness of basing an architecture on capabilities is one of those controversies. Here’s a definition of capability: the ability of an organization to use its assets to accomplish an activity that delivers business value or competitive value. I have memorized that phrase and can spout in out in my sleep. I can’t build a model of a capability that would stand up to a spring rain. Still, I see long threads on the business architecture discussion sites focused on how best to model “our unique ability to do ”. When the focus shifts solely to a linear process without a view of the integration points, I get worried.

A value stream is an end-to-end collection of activities that creates a result for a customer. The value stream has a clear goal: to satisfy or to delight the customer. “Delighting the customer” is a well-known phrase that comes to us from the Six Sigma and Lean Manufacturing disciplines.  

Some examples of strategic visioning value streams are “insight to strategy,” “vision to eBusiness enterprise,” “concept to development,” “initiative to results,” and “relationship to partnership.” At Railinc, because the business architecture function is new, one of the first things my team had to do was define an “initiative to results” value stream and integrate it with the product management team activities.

You may be familiar with some customer-centric value streams such as “prospect to customer,” “lead to cash,” manufacturing to distribution,” and “request to service.”  Business analysts are also typically deeply involved with business-enabling value streams such as, “forecast to plan,” “requisition to payables,” “resource availability to consumption,” “acquisition to obsolescence,” and “financial close to reporting.” People caring is another category of value streams, “recruitment to retirement” (less politically correctly known as “hire to fire”) and “awareness to prevention.”

I’ll go into value chains in a future article, but for now I just want to say that value chains are part of what a business architect builds. A value chain is a sequence of activities followed by a company in a specific industry. The chain of activities gives the product more added value than the sum of the independent activity’s value. As a simple example, take a master chocolatier as a profession. Cocoa mass, sugar, cocoa butter and dark chocolate nibs are low-cost ingredients by themselves. In the hands of a master chocolatier, the result can earn you forgiveness for leaving dirty socks on the living room floor, show appreciation to that analyst who went the extra mile for your study, or, eaten in private, could get you lucky on a date. The making of a chocolate confection may have a low cost, but the activity adds much of the value to the end product since the ingredients are significantly less valuable than a box of Recchiuti Confections. 

So, what do you do with a value chain? Once you have the value chain, in order to understand the behavior of costs for the product you can disaggregate a company (don’t be distracted by the divisions) into its strategically relevant activities. And you can examine the existing and potential sources of differentiation between your company and your competitors. Does your competitor have the ability to deliver a service in the same end-to-end capacity as your company can? Does that make you more interesting to potential customers? Understanding the value chains enables a company to gain a competitive advantage by performing these strategic activities more cheaply or better than its competitors.

What is the goal of Business Architecture?

In my opinion, the goal of a business architecture is to enable a company to focus its services on its customers. If you don’t know how the information in your company is integrated to enable delivery of services and customer satisfaction as well as being able to bill and collect for those services, then your company is in trouble. 

Case in point, what happens when you have multiple customer master databases? It is easy for this to happen. In my previous company, we grew by acquisition. With each new acquisition came at least three customer master files, one from the sales group, one from marketing and one from customer service. In my current company, we are in the process of integrating the customer master files associated with siloed products. One of the driving issues is data quality; when you have multiple sources of the same data, but no process for “single source of truth,” it can be impossible to know what is the most current data set for a customer. To achieve the goal of a single customer master file a company has to have an integrated model of customer touch-points. I don’t know about you, but I hate getting “exceptional offer for new customer” announcements from a service provider that I already have a contract with, especially when I see what good deal I would get if I weren’t already a customer. Makes me wonder if a competitor might match that new customer offer.

Rethinking “The Customer is #1” idea

A short tangent, indulge me. I’ve never liked the idea of the Customer being #1. In my mind, the employees should be #1 because if the employees are treated well they will perform well and treat the customer well and make the customer feel like they are #1.

In a previous company that I’ve worked for, if a customer became difficult to work with, one question that was always on the table was, are they worth doing business with? We could quantify that answer in terms of revenue versus lost productivity dealing with them and low employee job satisfaction. There’s a ceramic urn on top of the refrigerator in the employee break room at that company labeled “ashes of former customers.” I can’t tell you how much employee loyalty that urn evokes; I can tell you that in that urn are the names of companies we stopped doing business with because management decided it was bad business.

My employer, Railinc, is a subsidiary company of the American Association of Railroads. Having never worked for a subsidiary company before, I was surprised when I realized that one piece of advice that has been in my toolkit is no longer applicable — Railinc cannot fire any of its customers. We can’t single out a particular railroad and say, “We won’t do business with you.” A new twist in the life of an information worker.

Does making the employee “#1” conflict with the goal of a customer-centric business architecture? Not at all. It just means that a company needs to examine its business goals and determine the different aspects of “the customer,” i.e., revenue source and cost-center if it wants to broaden its definition of “customer.” Customers aren’t just revenue sources; they are also sources for cost, as in customer-retention. Employee-retention is also a quantifiable asset. Revamping the definition of customer is one example of how thinking at the enterprise level changes the scope of a business analyst to business architect.

What does a Business Architect do?

Like the job description for a business analyst, the answer to that question seems to be dependent on the hiring manager. There’s lots of confusion between the role of the enterprise IT architect and the business architect. I can only tell you what I am and am not doing.

Currently my focus is on core elements of the industry, specifically railcar health and railcar utilization. My days are spent as follows:

  • Formulating frameworks and building models — by the bucket load
  • Writing concept documents
  • Critiquing project proposals
  • Preparing for and conducting knowledge elicitation meetings
  • Asking a lot of questions
  • Collaborating, facilitating, more collaborating
  • Identifying “services” in product offering visions
  • Tending an organic (constantly changing) ten-year roadmap

I do not research or recommend technologies. That’s doesn’t mean I can be ignorant of past or current technologies. In fact, being older and having been around when some of the legacy systems were built and understanding how difficult it is to migrate off those platforms has been beneficial. I leave the “how” of the solution to the enterprise architects. They come to the business architecture team for the “what do they need to do and why do they need to do it.”

In my current position, my scope of work isn’t a single company. Railinc provides information services to the railroad industry. The business architecture model that my team is building focuses not on a single enterprise but on the entire railroad industry.

What I don’t do is spend any time with UML, write formal requirements and work directly with the product developers. That experience prepared me for how I spend time now — working with people at the railroads, with Railinc business analysts, product managers, program managers, Railinc enterprise and data architects, and external industry subject-matter experts. 

I help articulate our products, current and future, in terms of services and value streams. In particular, I analyze railcar health and utilization information and integration points in terms of relationships to all external entities, other enterprise value streams and the events that trigger instantiation. I look at railcar health and utilization information from the perspective of what my company must produce to satisfy its industry partners, compete in a market and deal with its information suppliers.


If you can’t help but perceive the world around you in terms of business information needs and process and connections; if you can hold multiple points of view simultaneously; if the meta-modeling is part of your consciousness and you’ve had a blast being a business analyst and are looking for something more, then I strongly encourage you to start aiming your career at business architecture.

Recommended Reading

Google these:

  • The Outside-In Approach to Customer Service, Sarah Jane Gilbert
  • “You Can’t Cost-Justify Architecture,” John Zachman
  • “Converging Business Architecture Approaches,” article on

This book was published this year: Enterprise Business Architecture, by Ralph Whittle , Conrad B. Myrick 

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the roles of the business analyst and business architect, and to empower business analysts with tools, methods, strategies and confidence. A motorcycle enthusiast, she’s riding out the downturn in the economy by living a bicoastal life, living in California and working as a business architect at Railinc in North Carolina. Her friends have disqualified her from the “how far do you commute to work” contest on the grounds that she’s nuts.

Can Strategy Maps be Used in Business Analysis?

After attending a management workshop on strategic themes in an IT organisation, I started thinking about the potential uses for strategy maps. These maps help capture the management team’s thinking in a non-restricted manner and they facilitate effective communication amongst stakeholders.

The core value of the strategy map is that it shows value that is to be created within an organisation, and how different layers within the organisation are interconnected. It also helps to see both the drivers of change and the impact it’s going to create.

Business Analyst View

Can strategy maps be used in business analysis? The answer is yes. The map concept can be “re-used” with a few modifications to its layout. I created five perspectives and added five business objectives on the top. The reason for this is that each initiative within an organisation aims to satisfy business objectives. At the same time, each initiative is a source of change. An understanding of the direction of change and its impact on different layers within the organisation from different perspectives is the core goal of business analysis.

The 5×5 map illustrates cause and effect relationships between objectives and problem/opportunity layers. It facilitates communication with decision makers within the organisation by means of a vivid picture of constraints and limitations within each layer. It also allows you to see the effects of external or internal changes on the current state.

My practice shows that a lack of visibility across all layers at once heavily limits the ability of top management to see pain points and make a sound decision about resolving the problem.

Have a look at an example map:


Map Structure

The map has a simple structure. Five key business objectives are located at the top. They are Grow Revenues, Manage Risks, Increase Efficiency, Maintain Compliance and Enhance Customer Value. The perspectives of analysis are Governance & Standards, Customer, Vendor, Partner & Community, Business Functions & Interfaces, Internal Stakeholders, and Enabling IT Services. The map is just a single page, so a holistic picture can be presented to the decision makers. Another benefit of the map is that it provides a framework for managing programmes of change across different business departments within the organisation. Selecting an element within a layer will allow you to describe practically any scenario where a change is required.

Strategy map as a Communication Tool

The map can be used as an effective communication tool allowing you to tell a story of the required capabilities, proposed changes, expected benefits and achievement of business objectives. The map uses the language of the executives and it keeps them on a single page illustrating the business objectives and organisational layers simultaneously. The map facilitates  understanding of complexity of change and the required effort (money and human resources) to implement the change and helps assess organisational readiness to changes.

Lessons Learned

Each organisation evolves every day. It is not really visible from one day to the next but it sill takes place. It means that changes made yesterday have impact on today’s state and thus relationships between components of the map evolve too.

The map can be used to see the progress of changes at a high level. It can also be used to understand what new changes may be required to attain the desired objectives under the changing conditions in the organisational environment. The advantage for the executives is that operational details do not take up their attention, and they can focus on what is working, what is not, and why. The map helps identify new dependencies as projects move from stage to stage. My view is that the 5×5 map is a tool for understanding and managing change.

Practical Application

Let’s have a look at how the 5×5 map can be applied to real situations. Let’s take for example the Maintain Compliance objective and the Sarbanes Oxley Act of 2002 (SOX) as an external force driving a change within an organisation. Three sections in the SOX, namely 302, 404 and 409 are of  interest.

Section 302 requires CEOs and CFOs of public companies to certify the information in the company’s quarterly and annual reports along with the company’s internal controls.

Section 404 requires a clear responsibility of management for establishing and maintaining an internal control system and procedures for regular financial reporting. The section also requires an assessment of the effectiveness of the established control system and procedures.

Section 409 states that material changes in the financial condition of the organisation must be disclosed to the public.

All these requirements rely on the control systems and processes. Bearing in mind that no organisation can function without an information infrastructure (business applications and telecommunications), the control systems and processes should be interwoven with the information infrastructure. Without these controls in place the organisation won’t be able to track physical operations and reflect them in the financial postings that are a source of financial reporting.

Let’s go through the layers and perspectives to analyse what should be considered within the organisation to satisfy the SOX 302, 404 and 409 requirements.

Governance & Standards

From this perspective, we need to examine policies, procedures, corporate standards determining the responsibilities of management and employees, the limits of delegated authority given to key managers, the ethics controls established to ensure that all actions are taken in favour of the organisation and its environment. These key guiding documents outline the internal control system and describe specific controls, and where they are to be used.

This layer is important as it gives an overview of all business rules applied to business processes and embedded into the enabling IT services. 

          Customer, Vendor, Partner & Community

The Customer & Community perspectives both refer to the public and shareholders. The organisation deals with them differently depending on elements within the layer. We need to look at the services provided to customers and communications with customers and community to ensure that the organisation uses the information. This excludes potential complaints and claims of misleading which may lead to a breach of compliance. It means that we need to see if the communicated information is obtained from reliable sources of actual transactions, and who has access to the information.

The Vendor & Partner perspectives are used to look at the transparency of relationships between the organisation and its external parties (supply chain), monitoring and reconciliation of all physical and financial transactions and fair provision of goods and services.

            Business Functions & Interfaces

The Business Functions perspective enables us to analyse the organisational value chain, as well as how functions are shared across the organisation. It facilitates a better understanding of  organisational structure, business processes within each business department and how they complement each other. Using the information obtained from the Governance & Standards perspectives, we can verify the established controls and rules, check their efficiency, reveal potential weaknesses and thus propose the required changes.

The Interfaces perspective comes in handy for analysing departmental boundaries, how the business information is passed on, what transformation of business data takes place within the processes and what IT enabling services are used within the business processes.

As the organisation operates in its environment, this perspective gives us an opportunity to analyse how the organisation cooperates with its environment, what communication channels are and whether they are manual or automated, what rules are applied to the flowing information, etc.

            Internal Stakeholders

Any policies and rules apply to people within the organisation so this perspective is focused on personnel, designated roles, skills, levels of competency and understanding of requirements imposed by the organisation itself and its external environment. This perspective facilitates an understanding of stakeholders’ perception of organisational culture, as well as how culture facilitates acceptance of internal controls and willingness to enforce them on a daily basis.

            IT Services

The last perspective is useful for the analysis of enabling IT services which include business applications, communication means and IT infrastructure. They can be analysed in terms of:

  • criticality to the business
  • ability to protect and control access to sensitive information
  • levels of compliance with regulatory requirements
  • potential impact on financial reporting
  • availability and business continuity measures
  • disaster recovery measures
  • scheduled service resiliency testing
  • backups
  • physical access controls
  • audit trails


The 5×5 map describes the drivers of change, the direction of change, what problem/opportunity layers should be considered when a change is to be made in order to achieve a business objective, what the constraints and limitations within each layer are, and what changes will be required to each layer. It is a useful analysis and communication tool for business analysts.

Don’t forget to leave your comments below.

Sergey Korban has been in the IT industry for over 25 years and has hands on experience in business analysis, project management and software development management. He is passionate about making businesses more effective. You can find more of his articles on the Aotea Studios blog (

Why Business Analysis Processes are a Waste of Time

Kupe_Feature_Oct18_CroppedI recently read a sales blog post, Why Sales Scripts are a Waste of Time, where the author talked about the need for sales professionals to adapt their approach based on the customer they are selling to and not follow a standard script or process they learned through sales training.  Rather than follow a process step by step a sales professional should use the steps as a framework.

The same applies to the business analysis community and a business analysis process. There are techniques, skills, tasks and approaches you have at your disposal.  It is the collection of those that will help you adapt your approach for each project.   The projects our community works on are not to build widgets.  The Ford Motor Company requires a consistent manufacturing process. Ford wants to make sure every Ford Fusion that is built looks and acts the same.  They fine tune their manufacturing process and make sure it is as repeatable as possible. There are steps that are followed A to Z with no deviation to ensure consistency.  Yes, different lines of a model include different steps, but you get the picture. 

In manufacturing following a process step by step is a good thing. In our world this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project. With that said there are two must steps.  One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives.  There should be a consistent start and a consistent end.  Everything in between should be flexible.

At the beginning of a project or iteration you and the team need to plan the approach.  The team needs to determine what steps you’ll take during the project.  You as the expert need to provide your thoughts and advice for the analysis steps, but you should not determine your approach in a vacuum.  Your team needs to buy-in to the approach and ensure their needs will be met to ensure a successful project. 

Things never go perfectly, so you should be inspecting your approach as you go and make adjustments.  At the end of a project or iteration you should inspect and learn to improve for your next initiative.

Let me end by stating I don’t think you should have to make everything up in between your plan and retrospective for every project.  You should have a base approach that you use as a framework.  Just use that as a starting point to add and/or remove steps to customize your approach for the specific project. 

All the best,


Don’t forget to leave your comments below.

Enough Business Analysis Already


The topic of the week for me has been knowing what is enough or the definition of done.  I attended a presentation at an IIBA chapter meeting where we discussed the importance of having one view of done for a task or deliverable. On a LinkedIn group a question was asked related to techniques to help BAs determine when you have enough requirements.  There is one technique used to determine when you have enough requirements.  That technique is… talking. 

I am a big believer in doing what is necessary for a project to be successful.  Most people, I hope all, agree you don’t follow a process just to follow a process.  You don’t complete an entire template because there is space to fill in.  You document what is necessary and you follow process steps because they add value to the project.

This is where talking comes in.  Determining when you have enough requirements is not the sole responsibility of the business analyst.  The team needs to determine how much is needed to move to the next stage.  Defining done or enough is in the eye of the receiver of the information, not the one eliciting and communicating the information. 

There tends to be a belief that a senior BA should know when enough is enough.  Without interaction from the receivers of the information any BA is just taking a guess. If a senior BA knows when enough is enough on their own, they are mind readers.  A senior BA knows what enough is because they talk with the receivers of the information to make that determination. 

It all comes back to determining what needs to be done in order to meet the goals of the project.  Together the project team, which includes the business stakeholders, makes that determination.  Once an initial determination is made there should be continual discussions or check-ins to ensure you have the right level. As the BA you need to adjust and adapt as necessary.  Maybe stopping before you thought or continuing to elicit and analyze more than anticipated.

That’s enough about enough…this blog post is done!


Don’t forget to leave your comments below.

O User, Where Art Thou?

In my previous article (, I referenced the Standish Group’s CHAOS Report, which stated that the biggest issue leading to project pain is lack of user input.  Anyone reading this blog should know that user participation is a vital part of the software development lifecycle (SDLC).  Therefore, you should interview customers for requirements early and as often as possible in the SDLC.  Since you can’t get input from every user, you will need to place users into groups of user classes, which are based on the features and functions that are most utilized by each class.  Each of these user classes will have its own prioritized set of user, functional and non-functional requirements.  Once you have identified the different user classes, you will need to name the product champion within each user class.  This is a person who has expert understanding and decision-making power to formulate requirements on behalf of the user class they are representing. Even if you can locate this spokesperson, they will have other tasks in their day-to-day life that will compete with the time you need to spend with them.  For this reason, you should make a request to the champion’s management, letting them know that the champion’s involvement is a priority.

Since most projects have several user classes and each person knows something different from the others, you will need a small number of these product champions.  During requirements elicitation, each of these champions will get involved often and at different times depending on the function/feature/process being detailed.  You should look for one representative per user class, and sometimes you can get lucky by finding someone who can represent several user classes.  This product champion should be able to communicate requirements, suggest ideas, reconcile between contradictory information and help you arrive at a cohesive set of requirements for their user class.  This person also needs to make key decisions, which means they need to be informed, respected and be an effective communicator within their user class.  In a model situation, product champions are located with the analysts, testers and developers, and can devote their entire time to answering questions and providing all the necessary details during requirements elicitation.  In reality, few champions are located with the analysts, testers and developers.  Also, you are fortunate if you can get a couple of hours a day of the champion’s time due to other tasks they need to perform within the organization.  Therefore, when selecting project champions, look for the following traits and factors:

  • They must be knowledgeable and respected within their user class.
  • They need to understand and be committed to their tasks as product champions.
  • They should have the time to commit and their management should encourage their involvement.
  • They should have the power to make key decisions.  If product champions do not have the power or the willingness to make the necessary decisions, then the developers will make them for them.  This is not a good idea because developers usually do not have the right point of view to make the best decisions for the business.

There are situations where the analyst has very little or no access to the real users.  This happens quite a bit when developing commercial software products for a new or emerging market.  In these cases, you need to use surrogate users versus real user champions.  This can be a product manager or a subject matter expert (SME) in the field.  There are a couple of groups to stay away from if you are going to choose surrogate users.  Avoid the manager of the real users as a surrogate champion.  Usually, managers don’t use the product like the real users use the product.  Secondly, managers don’t have the time to fully dedicate themselves during requirements elicitation.  Another group to avoid as a surrogate champion is the software developer.  Unless the developers themselves are using the product, they do not make good surrogates because developers have a different point of view of the product than the actual users.

If your stakeholders do not put a priority on allowing product champions to work with analysts then tell them this: you’re going to need to get user input now if you want to spend less time, money and cause less frustrations during user acceptance testing.  Your projects will be less “challenged” when you get user input early and often during requirements elicitation versus waiting until the system is in testing or in production.  If the stakeholders can’t get users or surrogates during requirements elicitation then this indicates that there is little assurance of the success of your project.

Don’t forget to leave your comments below.

Zeena Kabir is a Sales Engineering Consultant for Blueprint Software, the leader in requirements definition and visualization software. Prior to Blueprint, Zeena has worked 20+ years in the IT field in the areas of requirements engineering, testing, and development. She holds a Bachelor of Science degree in Computer Science and a Master of Science degree in Software Engineering from the University of Maryland. She resides and works with many IT organizations in the Mid-Atlantic region.