Tag Archives: Enterprise Architects

What is Business Architecture? Part 2

By Allen Brown, President and CEO, The Open Group

I recently wrote that I had heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So I wrote to 183 people in Australia and New Zealand and asked them.

The initial summary (blog) of the responses I received was focused on the feedback from Business Architects who were employed by organizations I think of as consumers; this one is focused on the feedback from consultants, ranging from those who are working on their own to others who are working with some of the largest consulting firms that we know.

Why I chose the countries I did and the questions I asked are contained in that earlier blog.

Again the responses have been amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their beliefs with respect to Business Architecture.

Summarizing the feedback from the consultants is even more difficult than that of the consumers.  Understandably, each of them has their own approach.  I have found it very difficult to decide what to leave out in order to get this down to a reasonable length for a blog.

It is important to repeat that I am still in the process of seeking to understand, so I would be really pleased to hear from anyone who has such a role, to correct any misunderstandings I might have or erroneous conclusions I may have drawn.

The first point of note from the responses is that Business Architecture is still evolving and finding its place in the enterprise.  While the consumers saw it as somewhere between immature and missing in action, the consultants tended to look at the how and why of its evolution.  In one case the view was that Business Architecture is evolving in response to a demand for greater business oriented control over transformation, while another reported, disappointedly, that business architecture is often seen as Business Process Review/Improvement on steroids.  Other comments included:

  • Generally Business Architecture is seen as business process review and/or business process improvement. There is not much real Business Architecture going on at the moment.
  • It is not widely understood at this point in time.  This first initiative will be conducted in a lightweight manner to gain the business buy in and get some projects onto the roadmap.  Delivery time will be a key factor in prioritization as we will be looking for some projects with shorter duration and lower complexity so some tangible benefits can be realized
  • It is not formally recognized.  Last year I was in the supply chain team (who also deal with Lean and other operational improvement skills).  We have Business Analysts, and a People and Change Team.  We have several areas than do Operating Models.  To me various elements of these would be included under the Business Architecture banner.

In common with the consumer viewpoint, the focus of Business Architecture is on the “What”.  Some of the comments included:

  • The Business Architecture will exist with or without technology, but as soon as technology is involved, the technology exists to service the business architecture, and the business architecture should be the input to the technology and application architecture.
  • Make recommendations of what projects the business should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information
  • The business architecture I am referring to is not the traditional element of the IT based Enterprise Architecture, but a framework that is totally business oriented and in which the whole business, including IT, can commit to in order to truly understand their problems and most of all the potential to genuinely improve the business.
  • “Business Architecture is not about telling people how to do their job at a detail level. Its function is to help us all to understand how together we can achieve the business goals and objectives
  • The primary focus of the Business Architect 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.

In some cases the focus of activity was the entire enterprise: the CEO view.  In others it was at the line of business or business unit level.  In all cases the focus was very much on the business issues:

  • Strategy
  • Business goals, objectives and drivers
  • Business operating model
  • Organization structure
  • Functions, roles, actors
  • Business processes
  • Key data elements

Being able to see the big picture and have the ability to communicate with key stakeholders was emphasized time and again.

  • Make it relevant and “makes sense” to senior management, operations and IT groups.  Visualize problems; have a way to communicate with the business team
  • Be able to relate – what big decision we need to make and to package it up so that execs can make a decision
  • The only person who cares about the whole picture is the CEO.  BA provides the CEO with a one page picture of the whole enterprise in a logical fashion
  • Show the CEO where impact is on a page – give confidence – control.  Help him make decisions around priorities.
  • The secret of good architecture is taking all the complexity and presenting it in a simplistic way that anyone can understand on a ‘need to know’ basis and quickly find the right answer to the current and/or planned state of business components.
  • BA facilitates strategic consistency with the business.  Where do we need to differentiate more than others?  How do we build in once or move to one instance?
  • Drive prioritization of when to invest based on the businesses strategic goals
  • Distil, communicate and relate to a business person
  • A key purpose of this new business driven architecture is to provide the means for communicating and controlling the strategic and operational intentions of the business in a way that is easy to understand for everyone in the organization

A common feature in the feedback is that underneath the models the information is rich – enables drill down – traceability to underlying requirements linked to the requirements.

Two areas of activity stood out the most: Capabilities and Value Streams.  Both of these are focused on WHAT a company needs to be able to do to execute its business strategy and to bring a product or service to a consumer.  Comments included:

  • Capabilities – combination of people, process and technology to deliver product features
  • Logical building blocks – gather information and compare the level of maturity in each capability, compare with others, understand where could we go to
  • Define/ champion 1 common reference model / capability model / logical building blocks of the enterprise.
  • Establish Capability, Information maps, Value Streams, stages and business processes.
  • Have intimate knowledge of the Business Capability (As Is/To Be), Business Component Structure, Business Processes, Value Streams and Conceptual Business Models.
  • Have the capability picture
  • … not only the capability of each component but also the relationship between components from every appropriate perspective (purpose, technical, compliance, risk, acceptability, etc.)
  • The Business Architecture is the first stage in a broader EA initiative.  Subsequent phases will align capabilities to applications and look at the major data flows between those applications

Since value stream mapping is a lean manufacturing technique, lean techniques are also called out as being relevant to business architecture because they identify areas of waste, which often change work processes or procedures, which may or may not impact applications and technology.  Feedback included:

  • Each value steam has Inputs (that triggers the value stream) and Outputs (the value based result of completing the business activities).
  • Each value stream is designed against Critical Success Factors, founded on the strategic intentions and priorities of the business, that represent the required business performance with Time, Cost, Quality, Risk and Compliance.
    • Time – How long the process should take from a Customer Perspective
    • Cost – How much the process should cost, measured using for example TDABC (Time Driven Activity Based Costing)
    • Quality – A statement clearly describing the (fit for) purpose of the activity
    • Risk – The protected acceptable residual risk involved due to effective control within the proposed design
    • Compliance – The specific interpreted requirements placed on the activity by interpreting the obligations of associated legislation and regulations.
    • Value streams are directed or informed by policies, plans, procedures, governance, regulations, business rules and other guidance, and are enabled by roles, IT Systems and other resources that will directly or indirectly support their completion.
    • The As-Is Architecture consists of the related value streams, indicating how the business is currently performing.   Under the facilitation of the business architect, design teams investigate how these can be improved to produce the Target State version of the Value Stream.

It was argued that displaying the relationship between the guidance, the enablers and the value streams, opens up the potential to discuss many things related to the business performance; that this alignment is critical for ensuring the business functions operate as expected; and that this is the major feature of business architecture and provides answers to so many previously unanswered questions for business managers.

Incidentally, since value stream maps are often drawn by hand in pencil (to keep the mapping process real-time, simple and iterative by allowing for simple correction) this tends to reinforce the comment by one of the consumer respondents that his most useful tools are pencil and paper.

The role and relationship of Business Architects, Business Analysts and other folk that might come under the general heading of Enterprise Architecture, varied from one organization to another, often seemingly dependent upon the size of the consulting firm.  At different ends of the spectrum were:

  • To a greater or lesser extent, Business Architects are supported by Business Analysts (“the knowledge processing factory) and by people with deep skills in design and process, Lean, 6 Sigma, HR, organization design and training.  The Business Architects ensure that all of the pieces fit together in a logical manor and that the impact can be shown in dollar terms
  • The Enterprise Architect is 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

The feedback on the title of Enterprise Architect was as varied as the number of responses.  The comments included:

  • Enterprise Architecture seen as a bad word
  • With hindsight, referring to it as architecture was a mistake
  • Enterprise Architecture is an IT version of technical specifications and drawings and not architecture, as such, and Enterprise Architects are mainly focused on the Application and Technology areas.
  • I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. In the future more Bus/Info architects will become Enterprise WIDE architects, not so much enterprise architects

In most cases but not all, there is no such job as an Enterprise Architect.  It is in instead the overall term for Business Architects, Solution Architects, Information Architects, Value architects, Journey architects and so on.

The key differences that were highlighted between the roles of Business Architect and Enterprise Architect was a matter of depth and potentially also of education:

  • Enterprise Architects will tend to have more depth in technology; Business Architects will tend to have more depth in business techniques
  • Enterprise Architects will tend to have a Computer Science degree, or similar; Business Architects will tend to have a business degree or experience.

It was also stated that Business Architecture is a logical growth path for an experienced Business Analyst provided they get an Enterprise level understanding of the Business and Architecture.

When I actually look at the background of the respondents, I can see experience in:

  • IT consulting
  • Operations management
  • Product management
  • Project management
  • Business Analyst
  • Aeronautical Engineering
  • Logistics
  • … and much more besides

and education backgrounds are similarly varied.

The common theme is a deep interest in the business issues and what makes organizations work.

The evolution of Business Architecture clearly has a long way to go and depends upon the ability of the practitioners to relate to the business leaders.  One respondent predicted a shift and a segmentation in these comments:

  • For business that serve the “mum and dads”. I believe you will see a grouping of the different architectures based upon the business objectives and capabilities.
  • I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. Applications and Technologies are all COTS nowadays (unless you are developing them). I think in the future more Bus/Info architects will become Enterprise WIDE Architects, not so much Enterprise Architects

The last word goes to the feedback that one Business Architect reported:

“In my time with this amazing new methodology I have had two separate reactions that stand out:

The first from an Acting CEO that was one of the biggest sceptics when I started the initiative and in admitting he had been, said that he owed me a big apology that he found the Business Architecture to be both highly useful and quite remarkable.

The second was in relation to a BPO initiative for a long standing traditional finance industry organization, when the chairman of the board said it [Business Architecture] had made a major decision relatively easy, that would have otherwise been one of the most difficult in the company‘s history.”

Allen Brown

Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  For over 14 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.

4 Comments

Filed under Business Architecture, Certifications, Enterprise Architecture, Enterprise Transformation, Professional Development, TOGAF

What is Business Architecture?

By Allen Brown, President and CEO, The Open Group

I have heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So I wrote to 183 people in Australia and New Zealand and asked them.

I chose Australia and New Zealand because of our conference in Sydney that was coming up at the time.  It is also worth mentioning that when counting the number of individuals in each country who have achieved TOGAF®9 certification, Australia is ranked 4th in the world and New Zealand is 20th.

I explained that I had thought of constructing a survey instrument but I always think that such an approach is only really suitable when you want to measure opinion on things that you know.  Since I really wanted to have an open mind, I asked everyone for their thoughts and provided a small number of open questions that showed the sort of thing I was interested in learning.

These were:

  • What is Business Architecture in the context of your organization?
  • Do you have Enterprise Architects in your organization? If so, what is it that you do that they do not? If not, how do you see Business Architecture differently from Enterprise Architecture?
  • Who do you report to? Is your line of reporting up to the CIO, the COO if you have one, or other senior level person?
  • How is Business Architecture perceived in your organization?

 It would also help me if I knew something about your organization.
  • Which industry are you in? e.g. IT, Oil, Finance, Healthcare, National or Local Government, etc.?
  • Is your organization primarily a consumer of Business Architecture or a supplier? e.g. consultant, trainer, vendor etc.
  • What type of organization do you work in? e.g. a for-profit entity, a government department, a charity, etc.
  • How big is the organization? Some idea of revenue or budget, number of employees – doesn’t have to be precise. You could just say small, medium or large.
  • How many Business Architects, Enterprise Architects or other architects are there in your organization?

And perhaps a little about yourself.
  • Your background e.g. Operations, Business Analysis, Project Management, IT, Finance etc.
  • Were you recruited for the role or did you develop into it?
  • I don’t wish to take up too much of your time but anything you can share would be very helpful. And please feel free to add anything else that you feel is relevant.

I have so far received 24 responses which is what I was hoping for but I am open to any other views people who are performing this role might have.  16 of the responses came from people employed by organizations that I think of as consumers of IT products and services (government departments, telcos, banks, accountants, energy companies, and mutuals) and 8 came from suppliers.

The responses were amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their organization, without of course divulging anything that they should not have.  But of course because I asked open questions, the responses are, at the same time both more complex and more interesting.  It’s a case of be careful of what you wish for – but I am really glad that I did.

So far I have been able to summarize the views of the consumers.  I will turn to the suppliers next.  It will be really interesting to see where the similarities and variations lay.

It is important to note that I am still in the process of seeking to understand, so I would be really pleased to hear from anyone who has such a role, to correct any misunderstandings I might have or erroneous conclusions I may have drawn.

A number of comments jumped out at me.  One example came from a Business Architect in a government department.  The reason it stood out was very simple.  Many times I am told that Business Architecture only applies to commercial business and cannot apply to governments or non-profits.  Which is strange to me, since I lead a non-profit and when I was at business school, part-time of course, a good proportion of my classmates were from the public sector.  The comment was in response to the question: who do you report to?  The answer was, “we report to the Secretary but all reporting lines are business focused”.

The first level of analysis, which should come as no surprise is that Business Architecture is a relatively new discipline for most organizations: in most cases it has been around for between 1 and 5 years.  Described by some as a growing capability, or as immature, or even as “largely missing”.  One respondent describes herself quite rightly as a pioneer.

A recurring theme was that the ability to have a company-wide or industry-wide model was critical as it provides a common terminology across the board to what the organization actually does and enables understanding of the implications of any changes.  Another was that the success or lack of it in Business Architecture really came down to the expertise of the people in the team; and another was that Business Architects acted very much, like internal consultants and often had a consulting background.

What Business Architects do is exactly that – their focus is on the “What”.  Some of the comments included:

  • Understanding strategic themes and drivers
  • Modeling value chains, value streams, configurations
  • Context modeling e.g. external interactions
  • Capabilities, including business capability, service capability (including both business and IT capabilities), capability maturity, targets and gaps
  • Calling out the interdependencies of all the business and architecture domains: strategy, governance, market, distribution, product, capability
  • Design – entities, people (organization structure, incentives), process, systems, functions, roles
  • Linking with and supporting the strategy and injecting into the investment planning cycle
  • The Business Architect provides processes, part of the input and information for the business to determine whether or not any investment will be made within their organisation

The “How” is in the domain of the Solution Architects, Application, Data and Technology Architects and the Business Analysts: business, process and data.

The crucial element is how well the Business Architects are integrated with the other architects and with the analysts.  In many cases Business Architecture was within the Enterprise Architecture function – as an aside it was pointed out by one or two respondents that they considered Enterprise Architecture as a function rather than a person – in other cases it was not.

The reporting lines for Business Architects varies from organization to organization.  Some reporting lines ultimately end up with the CIO or CTO, others to the COO and others did not.  In many cases they reported directly to a GM or Head of change management, transformation or business strategy or improvement.

In those cases where Business Architecture was not embedded within the Enterprise Architecture function the relationship was enabled via a forum or committee that brought the Business Architects together with those working on the other disciplines.   Gaining agreement on a common content framework, on business modeling standards and on governance procedures were cited as approaches that supported the collaboration.

Although in one case, Business Architecture was relegated to a sub-discipline of IT architecture to focus on the “business stuff”.  In most cases the Business Architects described a differentiated focus or role.

  • A focus on business performance, process design, organization design, strategy and planning
  • The documentation and governance of business processes, organizational elements, business requirements, regulatory requirements, business rules and risks
  • The description of what we are trying to do, what value it adds and how it can be done

The difference from the other architecture domains was often described under the general heading of technology.

  • Technical architecture and governance
  • Strategic solutioning
  • Information, application, data architecture
  • Portfolio management
  • The enterprise stack of tools
  • Innovation through new technology

Business Architecture often demands a certain amount of analysis work and in one case it was seen as glorified business analysis. I have also heard “industry experts” say that they do not understand the difference between Business Architects and Business Analysts.  But that is unfair both to the Business Architects and to the Business Analysts.  They are both important functions in their own right.  In fact it has been emphasized that you need all three disciplines: Business Analyst, Business Architect and the Solution, Information, Technology Architect.

Perhaps in smaller organizations you might get by with a Jack of all trades but the size of the organization represented by these respondents ranged from 1,500 employees to 50,000 employees and they need the benefit of the three different specializations.

While the Business Analysts are the source of the very detailed information needed, the Business Architect brings the skills needed to distil that information and discuss it with the business leaders.  The people they are talking with are the senior leaders, the strategic solutioning teams, the program directors of large change programs and others who need pragmatic, easily digestible information.  They need to understand the implications and gaps, the dependencies, the opportunities and the limitations.

As one person said, “the success gauge for Business Architecture is an organization that starts solving business problems by defining them within the organization’s context across the spectrum of change areas, minus the technology change area, and then works toward the technology, rather than starting at a technology solution that might solve the problem and playing catch-up from there.  I continue to hold to the view that investing in the Business Architecture up front saves on people, process and technology cost at the end.”

Again, I would like to thank everyone for taking the time to respond.  Everyone has a valuable story to tell and everyone is fully committed to the role and function of the Business Architect.  If I have misunderstood anything, please do not hesitate to correct me. I look forward to hearing your comments.

Allen Brown

Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  For over 14 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.

2 Comments

Filed under Business Architecture, Certifications, Enterprise Architecture, Enterprise Transformation, Professional Development, TOGAF

#ogChat Summary – Business Architecture

By Patty Donovan, The Open Group

The Open Group hosted a tweet jam (#ogChat) to discuss the evolution of Business Architecture and its role in enterprise transformation. In case you missed the conversation, here is a recap of the event.

The Participants

A total of 16 participants joined in the hour-long discussion, including:

The Discussion

Here is a high-level  snapshot of yesterday’s #ogChat discussion:

Q1 How do you define #BizArch? #ogChat

While not everyone could agree on a single definition, all agreed that Business Architecture enables operational ease and business model innovation.

  • @Dana_Gardner: Q1 Aligning the strategies and operational priorities of all a business’s groups along a common, coorindated path. #ogChat #BizArch #EA
  • @enterprisearchs: Q1 At @enterprisearchs we also believe #BizArch is the design of business to enable business model innovation #ogChat
  • @bmichelson: #ogchat q1: in reality, business architecture is more the meta model of business, used to understand, measure, deliver capability #BizArch
  • @MartinGladwell: Q1 Orchestrating the delivery of changes needed to realise the strategy #ogchat

 

Q2 What is the role of the business architect? What real world #business problems does #BizArch solve? #ogChat

Most agreed that the lines are blurred between the roles of the Business Architect and the Enterprise Architect. Both manage complexity, agility and data proactively within a business or enterprise.

  • @bmichelson: #ogchat q2: so, I differ here. I think *true* business architect designs the business; in reality, we assign “architect” to business analyst
  • @Dana_Gardner: Q2 #BizArch allows for managing complexity, fostering agility, makes a data-driven enterprise more able to act in proactive manner #ogChat
  • @editingwhiz: So much software now is aimed at line-of-business people that acquiring IT business architect creds would be a huge attribute. #ogChat
  • @MartinGladwell: Q2 Is an MBA an advantage for a BA? Is it necessary? #ogchat
  • @enterprisearchs: A2 Ensures an org is correctly positioned and the environmental/industry factors are understood in order to achieve its strategy #ogChat
  • @DaveHornford: Q2: all my answers chase their tails into architecture – what must I have to get what I want – what must change  #ogchat #bizarch

 

Q3 How is the role of the Business Architect changing? What are the drivers of this change? #ogChat #BizArch

Some argued that the role of the Business Architect is not changing at all, but rather just emerging (or evolving?), and that Business Architects are differentiating themselves from other organizational roles. Others argued that the role is changing to accommodate emerging trends and areas of focus (i.e,. customer experience).

  • @enterprisearchs: A3 Businesses are looking to differentiate, an increased focus on Customer Experience is raising questions on how to increase NPS #ogChat
  • @blake6677: #ogchat At the core of my Business Architecture practice is business capability modeling
  • @DaveHornford: Q3 – changing? Is just starting to appear – distinction between architect, strategist, analyst, change leader often hard to see  #ogchat

 

Q4 How does #BizArch differ from #EntArch? #ogChat

Similar to the discussion around question two, most participants agreed that the roles of Business and Enterprise Architects are difficult to separate, while some argued about the differences in scope of the two roles.

  • @NadhanAtHP: A4: @theopengroup Biz Architecture provides the business foundation for the Enterprise Architecture which is more holistic #ogChat
  • @DaveHornford: Q4: difference is in scope #BizArch is one of many domains comprising #EntArch #ogchat
  • @harryhendrickx: Q3 #BizArch evolves towards operational position serving many initiatives. Not sure how practice evolves #ogChat
  • Len Fehskens: Q4 “There is a lot of confusion about the meanings of #business and #enterprise, and many people use them synonymously” #Len #ogChat
  • @MartinGladwell @theopengroup Len I think there is no truth of the matter, we must choose to use these terms in a way that advances our common cause #ogchat
  • @enterprisearchs: A4 In TOGAF ADM we see #BizArch predominantly supporting the prelim and arch vision phases #ogchat

 

Q5 How can Business Architects and Enterprise Architects work together? #ogChat #BizArch #EntArch

All agreed that Business Architects and Enterprise Architects exist to support one another. When discussing the first step to establishing successful Business Architecture, participants suggested knowing its purpose first, then tapping professional accreditation and community involvement resources second.

  • @Dave Hornford: Ethnography within the enterprise, it’s ecosystem or both? #ogchat
  • @Dana_Gardner: Q5 They make each other stronger, and can provide an example to the rest on how these methods and tools can work harmoniously. #ogChat
  • @bmichelson: “@theopengroup: What is the first step toward establishing a successful #BizArch? #ogChat” < knowing why you want to establish practice
  • @MartinGladwell: @theopengroup #ogchat professional accreditation, community, role models

 

Q6 What’s in store for #BizArch in the future? #ogChat

When looking towards the future, panelists suggested erasing ambiguity when it comes to the difference between Business and Enterprise Architects. Others also predicted that the rising demand for Business Architects will spark a need for certification and training programs.

  • Len Fehskens: Q6 I fear conventional wisdom contradictions and ambiguities will be ‘resolved’ by setting arbitrary distinctions in concrete #Len #ogChat
  • @Dana_Gardner: Q6 I hope to see more stature given to the role of #BizArch, so that it becomes an executive-tier requirement. #ogChat
  • @bmichelson: #ogchat q6: learning how to enable continuous change via: visibility, context, correctness & responsiveness #BizArch
  • @MartinGladwell: Q6 #ogchat We will see information as a design activity not an analysis activity
  • @enterprisearchs: A6 The demand for #BizArch will  generate a need for recognised certification and training #ogChat
  • @allenbrownopen: Business architecture like other functions such as legal and finance can inform C level decisions, it can’t make them #ogchat

 

A big thank you to all the participants who made this such a great discussion!  Join us for our next tweet jam on Platform 3.0!

 

patricia donovanPatricia Donovan is Vice President, Membership & Events, at The Open Group and a member of its executive management team. In this role she is involved in determining the company’s strategic direction and policy as well as the overall management of that business area. Patricia joined The Open Group in 1988 and has played a key role in the organization’s evolution, development and growth since then. She also oversees the company’s marketing, conferences and member meetings. She is based in the U.S.

Comments Off

Filed under Business Architecture, Tweet Jam

Gaining Greater Cohesion: Bringing Business Analysis and Business Architecture into Focus

By Craig Martin, Enterprise Architects

Having delivered many talks on Business Architecture over the years, I’m often struck by the common vision driving many members in the audience – a vision of building cohesion in a business, achieving the right balance between competing forces and bringing the business strategy and operations into harmony.  However, as with many ambitious visions, the challenge in this case is immense.  As I will explain, many of the people who envision this future state of nirvana are, in practice, inadvertently preventing it from happening.

Standards Silos
There are a host of standards and disciplines that are brought into play by enterprises to improve business performance and capabilities. For example standards such as PRINCE2, BABOK, BIZBOK, TOGAF, COBIT, ITIL and PMBOK are designed to ensure reliability of team output and approach across various business activities. However, in many instances these standards, operating together, present important gaps and overlaps. One wonders whose job it is to integrate and unify these standards. Whose job is it to understand the business requirements, business processes, drivers, capabilities and so on?

Apples to Apples?
As these standards evolve they often introduce new jargon to support their view of the world. Have you ever had to ask your business to explain what they do on a single page? The diversity of the views and models can be quite astonishing:

  • The target operating model
  • The business model
  • The process model
  • The capability model
  • The value chain model
  • The functional model
  • The business services model
  • The component business model
  • The business reference model
  • Business anchor model

The list goes on and on…

Each has a purpose and brings value in isolation. However, in the common scenario where they are developed using differing tools, methods, frameworks and techniques, the result is usually greater fragmentation, not more cohesion – and consequently we can end up with some very confused and exacerbated business stakeholders who care less about what standard we use and more about finding clarity to just get the job done.

The Convergence of Business Architecture and Business Analysis
Ask a room filled with business analysts and business architects how their jobs differ and relate, and I guarantee that would receive a multitude of alternative and sometimes conflicting perspectives.

Both of these disciplines try to develop standardised methods and frameworks for the description of the building blocks of an organization. They also seek to standardise the means by which to string them together to create better outcomes.

In other words, they are the disciplines that seek to create balance between two important business goals:

  • To produce consistent, predictable outcomes
  • To produce outcomes that meet desired objectives

In his book, “The Design of Business: Why Design Thinking is the Next Competitive Advantage,” Roger Martin describes the relationships and trade-offs between analytical thinking and intuitive thinking in business. He refers to the “knowledge funnel,” which charts the movement of business focus from solving business mysteries using heuristics to creating algorithms that increase reliability, reducing business complexity and costs and improving business performance.

The disciplines of Business Architecture and business analysis are both currently seeking to address this challenge. Martin refers to this as ”design thinking.”

Thinking Types v2

Vision Vs. Reality For Business Analysts and Business Architects

When examining the competency models for business analysis and Business Architecture, the desire is to position these two disciplines right across the spectrum of reliability and validity.

The reality is that both the business architect and the business analyst spend a large portion of their time in the reliability space, and I believe I’ve found the reason why.

Both the BABOK and the BIZBOK provide a body of knowledge focused predominantly around the reliability space. In other words, they look at how we define the building blocks of an organization, and less so at how we invent better building blocks within the organization.

Integrating the Disciplines

While we still have some way to go to integrate, the Business Architecture and business analysis disciplines are currently bringing great value to business through greater reliability and repeatability.

However, there is a significant opportunity to enable the intuitive thinkers to look at the bigger picture and identify opportunities to innovate their business models, their go-to-market, their product and service offerings and their operations.

Perhaps we might consider introducing a new function to bridge and unify the disciplines?

This newly created function might integrate a number of incumbent roles and functions and cover:

  • A holistic structural view covering the business model and the high-level relationships and interactions between all business systems
  • A market model view in which the focus is on understanding the market dynamics, segments and customer need
  • A products and services model view focusing on customer experience, value proposition, product and service mix and customer value
  • An operating model view – this is the current focus area of the business architect and business analyst. You need these building blocks defined in a reliable, repeatable and manageable structure. This enables agility within the organization and will support the assembly and mixing of building blocks to improve customer experience and value

At the end of the day, what matters most is not business analysis or Business Architecture themselves, but how the business will bridge the reliability and validity spectrum to reliably produce desired business outcomes.

I will discuss this topic in more detail at The Open Group Conference in Sydney, April 15-18, which will be the first Open Group event to be held in Australia.

Craig-MARTIN-ea-updated-3Craig Martin is the Chief Operating Officer and Chief Architect at Enterprise Architects, which is a specialist Enterprise Architecture firm operating in the U.S., UK, Asia and Australia. He is presenting the Business Architecture plenary at the upcoming Open Group conference in Sydney. 

1 Comment

Filed under Business Architecture

On Demand Broadcasts from Day One at The Open Group Conference in Newport Beach

By The Open Group Conference Team

Since not everyone could make the trip to The Open Group Conference in Newport Beach, we’ve put together a recap of day one’s plenary speakers. Stay tuned for more recaps coming soon!

Big Data at NASA

In his talk titled, “Big Data at NASA,” Chris Gerty, deputy program manager, Open Innovation Program, National Aeronautics and Space Administration (NASA), discussed how Big Data is being interpreted by the next generation of rocket scientists. Chris presented a few lessons learned from his experiences at NASA:

  1. A traditional approach is not always the best approach. A tried and proven method may not translate. Creating more programs for more data to store on bigger hard drives is not always effective. We need to address the never-ending challenges that lie ahead in the shift of society to the information age.
  2. A plan for openness. Based on a government directive, Chris’ team looked to answer questions by asking the right people. For example, NASA asked the people gathering data on a satellite to determine what data was the most important, which enabled NASA to narrow focus and solve problems. Furthermore, by realizing what can also be useful to the public and what tools have already been developed by the public, open source development can benefit the masses. Through collaboration, governments and citizens can work together to solve some of humanity’s biggest problems.
  3. Embrace the enormity of the universe. Look for Big Data where no one else is looking by putting sensors and information gathering tools. If people continue to be scared of Big Data, we will be resistant to gathering more of it. By finding Big Data where it has yet to be discovered, we can solve problems and innovate.

To view Chris’s presentation, please watch the broadcasted session here: http://new.livestream.com/opengroup/Gerty-NPB13

Bringing Order to the Chaos

David Potter, chief technical officer at Promise Innovation and Ron Schuldt, senior partner at UDEF-IT, LLC discussed how The Open Group’s evolving Quantum Lifecycle Management (QLM) standard coupled with its complementary Universal Data Element Framework (UDEF) standard help bring order to the terminology chaos that faces Big Data implementations.

The QLM standard provides a framework for the aggregation of lifecycle data from a multiplicity of sources to add value to the decision making process. Gathering mass amounts of data is useless if it cannot be analyzed. The QLM framework provides a means to interpret the information gathered for business intelligence. The UDEF allows each piece of data to be paired with an unambiguous key to provide clarity. By partnering with the UDEF, the QLM framework is able to separate itself from domain-specific semantic models. The UDEF also provides a ready-made key for international language support. As an open standard, the UDEF is data model independent and as such supports normalization across data models.

One example of successful implementation is by Compassion International. The organization needed to find a balance between information that should be kept internal (e.g., payment information) and information that should be shared with its international sponsors. In this instance, UDEF was used as a structured process for harmonizing the terms used in IT systems between funding partners.

The beauty of the QLM framework and UDEF integration is that they are flexible and can be applied to any product, domain and industry.

To view David and Ron’s presentation, please watch the broadcasted session here: http://new.livestream.com/opengroup/potter-NPB13

Big Data – Panel Discussion

Moderated by Dana Gardner, Interarbor Solution, Robert Weisman , Build The Vision, Andras Szakal, IBM, Jim Hietala, The Open Group, and Chris Gerty, NASA, discussed the implications of Big Data and what it means for business architects and enterprise architects.

Big Data is not about the size but about analyzing that data. Robert mentioned that most organizations store more data than they need or use, and from an enterprise architect’s perspective, it’s important to focus on the analysis of the data and to provide information that will ultimately aid it in some way. When it comes to security, Jim explained that newer Big Data platforms are not built with security in mind. While data is data, many security controls don’t translate to new platforms or scale with the influx of data.

Cloud Computing is Big Data-ready, and price can be compelling, but there are significant security and privacy risks. Robert brought up the argument over public and private Cloud adoption, and said, “It’s not one size fits all.” But can Cloud and Big Data come together? Andras explained that Cloud is not the almighty answer to Big Data. Every organization needs to find the Enterprise Architecture that fits its needs.

The fruits of Big Data can be useful to more than just business intelligence professionals. With the trend of mobility and application development in mind, Chris suggested that developers keep users in mind. Big Data can be used to tell us many different things, but it’s about finding out what is most important and relevant to users in a way that is digestible.

Finally, the panel discussed how Big Data bringing about big changes in almost every aspect of an organization. It is important not to generalize, but customize. Every enterprise needs its own set of architecture to fit its needs. Each organization finds importance in different facets of the data gathered, and security is different at every organization. With all that in mind, the panel agreed that focusing on the analytics is the key.

To view the panel discussion, please watch the broadcasted session here: http://new.livestream.com/opengroup/events/1838807

Comments Off

Filed under Conference

Three Best Practices for Successful Implementation of Enterprise Architecture Using the TOGAF® Framework and the ArchiMate® Modeling Language

By Henry Franken, Sven van Dijk and Bas van Gils, BiZZdesign

The discipline of Enterprise Architecture (EA) was developed in the 1980s with a strong focus on the information systems landscape of organizations. Since those days, the scope of the discipline has slowly widened to include more and more aspects of the enterprise as a whole. This holistic perspective takes into account the concerns of a wide variety of stakeholders. Architects, especially at the strategic level, attempt to answer the question: “How should we organize ourselves in order to be successful?”

An architecture framework is a foundational structure or set of structures for developing a broad range of architectures and consists of a process and a modeling component. The TOGAF® framework and the ArchiMate® modeling language – both maintained by The Open Group – are two leading and widely adopted standards in this field.

TA 

While both the TOGAF framework and the ArchiMate modeling language have a broad (enterprise-wide) scope and provide a practical starting point for an effective EA capability, a key factor is the successful embedding of EA standards and tools in the organization. From this perspective, the implementation of EA means that an organization adopts processes for the development and governance of EA artifacts and deliverables. Standards need to be tailored, and tools need to be configured in the right way in order to create the right fit. Or more popularly stated, “For an effective EA, it has to walk the walk, and talk the talk of the organization!”

EA touches on many aspects such as business, IT (and especially the alignment of these two), strategic portfolio management, project management and risk management. EA is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of an EA capability in the organization is typically approached as a change project with clearly defined goals, metrics, stakeholders, appropriate governance and accountability, and with assigned responsibilities in place.

With this in mind, we share three best practices for the successful implementation of Enterprise Architecture:

Think big, start small

The potential footprint of a mature EA capability is as big as the entire organization, but one of the key success factors for being successful with EA is to deliver value early on. Experience from our consultancy practice proves that a “think big, start small” approach has the most potential for success. This means that the process of implementing an EA capability is a process with iterative and incremental steps, based on a long term vision. Each step in the process must add measurable value to the EA practice, and priorities should be based on the needs and the change capacity of the organization.

Combine process and modeling

The TOGAF framework and the ArchiMate modeling language are a powerful combination. Deliverables in the architecture process are more effective when based on an approach that combines formal models with powerful visualization capabilities.

The TOGAF standard describes the architecture process in detail. The Architecture Development Method (ADM) is the core of the TOGAF standard. The ADM is a customer-focused and value-driven process for the sustainable development of a business capability. The ADM specifies deliverables throughout the architecture life-cycle with a focus on the effective communication to a variety of stakeholders. ArchiMate is fully complementary to the content as specified in the TOGAF standard. The ArchiMate standard can be used to describe all aspects of the EA in a coherent way, while tailoring the content for a specific audience. Even more, an architecture repository is a valuable asset that can be reused throughout the enterprise. This greatly benefits communication and cooperation of Enterprise Architects and their stakeholders.

Use a tool!

It is true, “a fool with a tool is still a fool.” In our teaching and consulting practice we have found; however, that adoption of a flexible and easy to use tool can be a strong driver in pushing the EA initiative forward.

EA brings together valuable information that greatly enhances decision making, whether on a strategic or more operational level. This knowledge not only needs to be efficiently managed and maintained, it also needs to be communicated to the right stakeholder at the right time, and even more importantly, in the right format. EA has a diverse audience that has business and technical backgrounds, and each of the stakeholders needs to be addressed in a language that is understood by all. Therefore, essential qualifications for EA tools are: rigidity when it comes to the management and maintenance of knowledge and flexibility when it comes to the analysis (ad-hoc, what-if, etc.), presentation and communication of the information to diverse audiences.

So what you are looking for is a tool with solid repository capabilities, flexible modeling and analysis functionality.

Conclusion

EA brings value to the organization because it answers more accurately the question: “How should we organize ourselves?” Standards for EA help monetize on investments in EA more quickly. The TOGAF framework and the ArchiMate modeling language are popular, widespread, open and complete standards for EA, both from a process and a language perspective. EA becomes even more effective if these standards are used in the right way. The EA capability needs to be carefully embedded in the organization. This is usually a process based on a long term vision and has the most potential for success if approached as “think big, start small.” Enterprise Architects can benefit from tool support, provided that it supports flexible presentation of content, so that it can be tailored for the communication to specific audiences.

More information on this subject can be found on our website: www.bizzdesign.com. Whitepapers are available for download, and our blog section features a number of very interesting posts regarding the subjects covered in this paper.

If you would like to know more or comment on this blog, or please do not hesitate to contact us directly!

Henry Franken

Henry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

 

 

sven Sven van Dijk Msc. is a consultant and trainer at BiZZdesign North America. He worked as an application consultant on large scale ERP implementations and as a business consultant in projects on information management and IT strategy in various industries such as finance and construction. He gained nearly eight years of experience in applying structured methods and tools for Business Process Management and Enterprise Architecture.

 

basBas van Gils is a consultant, trainer and researcher for BiZZdesign. His primary focus is on strategic use of enterprise architecture. Bas has worked in several countries, across a wide range of organizations in industry, retail, and (semi)governmental settings.  Bas is passionate about his work, has published in various professional and academic journals and writes for several blogs.

2 Comments

Filed under ArchiMate®, Enterprise Architecture, TOGAF®

Successful Enterprise Architecture using the TOGAF® and ArchiMate® Standards

By Henry Franken, BiZZdesign

The discipline of Enterprise Architecture was developed in the 1980s with a strong focus on the information systems landscape of organizations. Since those days, the scope of the discipline has slowly widened to include more and more aspects of the enterprise as a whole. This holistic perspective takes into account the concerns of a wide variety of stakeholders. Architects, especially at the strategic level, attempt to answer the question “How should we organize ourselves in order to be successful?”

An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures and consists of a process and a modeling component. TOGAF® framework and the ArchiMate® modeling language – both maintained by The Open Group® – are the two leading standards in this field.

TA

Much has been written on this topic in online forums, whitepapers, and blogs. On the BiZZdesign blog we have published several series on EA in general and these standards in particular, with a strong focus on the question: what should we do to be successful with EA using TOGAF framework and the ArchiMate modeling language? I would like to summarize some of our findings here:

Tip 1 One of the key success factors for being successful with EA is to deliver value early on. We have found that organizations who understand that a long-term vision and incremental delivery (“think big, act small”) have a larger chance of developing an effective EA capability
 
Tip 2 Combine process and modeling: TOGAF framework and the ArchiMate modeling language are a powerful combination. Deliverables in the architecture process are more effective when based on an approach that combines formal models with powerful visualization capabilities. Even more, an architecture repository is an valuable asset that can be reused throughout the enterprise
 
Tip 3 Use a tool! It is true that “a fool with a tool is still a fool”. In our teaching and consulting practice we have found, however, that adoption of a flexible and easy to use tool can be a strong driver in pushing the EA-initiative forward.

There will be several interesting presentations on this subject at the upcoming Open Group conference (Newport Beach, CA, USA, January 28 – 31: Look here), ranging from theory to case practice, focusing on getting started with EA as well as on advanced topics.

I will also present on this subject and will elaborate on the combined use of The Open Group standards for EA. I also gladly invite you to join me at the panel sessions. Look forward to see you there!

Henry FrankenHenry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

2 Comments

Filed under ArchiMate®, Enterprise Architecture, TOGAF®