Sunday, November 6, 2016

Blog #6 - Business Architecture

Business Context
We have heard plenty about aligning business strategy and IT execution as a core of Enterprise Architecture. While this is important we have also heard about making sure to look at business context as part of it. According to Malik (2016), "A business analyst may start with some bit of strategy and start hunting for capabilities… a business architect will start with a model of the enterprise, its value streams and its business models. Starting with strategy is a fool’s errand." He continues to describe why starting with business strategy is not a good approach and states that the "business model comes first, and the strategy comes second."

This article takes a direct stand that business context and business model are the most important part of business architecture. For me this is something I need to get a better handle on and define more completely. I think most folks have a good understanding of what their business does and has some idea of the context that the business operates under. To be successful in an EA practice it is important to get the full view and understand the big picture around the business model and context.

I like the graphic included in Malik (2016) showing how the business strategy helps move from today's business model to tomorrows business model. This helps to understand that the business model needs to continue to be reviewed and then align the business strategy to accomplish the goals of the business model.

Reference
Maklik, Nick (2013). Business Architects: Do Not Start With Strategy. Retrieved November 5th, 2016 from https://blogs.msdn.microsoft.com/nickmalik/2013/08/24/business-architects-do-not-start-with-strategy/

Don't Boil the Ocean
How many times have we hear the phrase "don't boil the ocean" when it comes to EA. The same holds true for business architecture. Fenster (2016) reaffirms that statement and goes on to say, "The business case for a central architecture team is a difficult one to write and to get approved in a changing world." He goes on to say that "Embedding architecting skills within individuals, who then operate in different roles across the organisation, rather than training specialists and placing them in vunerable teams is growing as the alternative way forward."

This is driving to the idea of agile architecture. I like the idea of agile architecture, it provides a way to get value from EA without having to define an execution plan for a full blown EA practice. With organizations that have a diverse portfolio or a large strategic footprint that needs to be accounted for using an agile approach to architecture seem like the only way to show the incremental benefits of EA.

For my organization this seems like the only way to make progress on an EA front and to continue to understand and show value. By addressing problem area in regards to business context and strategy in bit size pieces it becomes each to show the value in EA. Also with give the challenge of time allocated to running the business any time that can be spent architecting will add significant value even if in incremental stages.

One question I would have for the group would be, does anyone have experience using an agile architecture approach?

Reference
Fenster (2016). Business Architecture " Don't boil the Ocean". Retrieved November 5th, 2016 from http://businessarchitectsblog.blogspot.com/2016/09/business-architecture-dont-boil-ocean.html

Business Architecture
I found the article from Bergsman (2013) interesting. He provides a couple tips to getting business architecture off the ground. He touches on a couple things that we have heard many times before in EA. One is orienting EA around the business and not technology and another is using the business as the foundation of EA. These things are not new but I thought the graphic he provides has some additional subtle annotations that I haven't seen before. The recommendations with the green checkmarks and the things to avoid with the red x's.



In addition to the graphic I like his definitions of the two types of business architectures. Below are his two definitions from his article.
  1. Business Model Architecture—Captures the business model as it changes with business strategy. This type of architecture identifies and maps changes to supplier relationships, channel management, customer relationships, and other strategic-level organizational areas. It may also be known as business drivers in some organizations. 
  2. Business Operations Architecture—Captures the operating capabilities necessary to enable business strategy. This type of architecture identifies and maps changes to the business capabilities required for the organization to operate and adapt to changes in strategic direction. 
These two types of business architecture will be help and important to remember as we build our EA practice.
Reference
Bergsman, Jeremy. (2013). Tips for Getting Business Architecture Off the Ground. Retrieved November 6th, 2016 from https://www.cebglobal.com/blogs/tips-for-getting-business-architecture-off-the-ground-3/

1 comment:

  1. I agree on the importance of establishing the business model and business context first. Wherever I go in my career, one of the first things I do is to create a Business Context model, which shows how the business interacts with its external environment. It is strictly business oriented and not technology based whatsoever. I sometimes limit it to individual lines of business if the enterprise is large and diversified. It usually fits on one page and simply shows the external organizations or organization types that the enterprise engages with to produce goods or services. All external organizations that are ancillary to the value chain, such as the cleaning or landscaping services are excluded for obvious reasons. Anyway, that’s what I call a business context. Thanks for a great posting.

    ReplyDelete