Reflection 1: Five Core Principles of Successful Business Architecture
For this reflection, the authors provide not only five core principles of a successful business architecture, but they augment it with five addition items of importance. There are two key points from the article’s bullets (from both the set of five core principles and the additional list of points called the “Other Big Five”) which will help both Enterprise and Business Architects get to the core of what a business architecture is.
Before getting into the two key points, I want to praise the authors for presenting their points in a simple, easy to remember manner. The challenge I have with disciplines such as Enterprise or Business Architecture are with many of the terminology definitions - it seems simplicity is often forsaken for protracted and convoluted definitions. For instance the “Business Architecture” definition on Wikipedia states:
Business architecture is defined as "a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”
The above definition would be more helpful if it simply stopped at “a blueprint for the enterprise”. Everything else seems excessive and even confusing. How many people really know what “aligning strategic objectives and tactical demands” really means? It’s this kind of verbose excess that made me appreciate the above article. The core principles and additional items are presented simply and succinctly and are easy to remember. Supporting detail is, of course, provided within the document.
The first key point is the absolute exclusion of technology from the business architecture. The first of the five core principle bullets states that business architecture is about the business. It is not about IT and technology. Technology should not be reflected at all in a business architecture. Very closely related to this core principle is the third bullet from the set of the “other big 5”. That bullet states that a business architecture does not directly feed software development. If a business architecture contains processes on how a software application is used or even contains detailed, low-level processes, it’s likely to fail. A good business architecture should simply help people understand the business and, of course, help plan for change.
The second key point comes from the second of the five core principles. This bullet states that business architecture is not prescriptive. In other words, there is no single recipe for enterprises to follow. Seeking input and knowledge from other organizations is important, but we must remember that what we learn is not meant to be applied verbatim.
If we remember that a business architecture is a blueprint for a business, if we keep technology out of it and avoid low-level processes, if we remember that every organization is unique and thus should expect to develop a business architecture that looks like none other before it, then we will have a solid and simple understanding of business architecture.
In my Enterprise Architecture Foundations I class at Penn State, I recall learning how organizations cannot exist in a vacuum and instead must exist in an environment. Furthermore, the teachings went on state that an organization is defined by how it interacts with its environment, not what goes on within the organization. This class material was presented as long-held and accepted beliefs on what an organization is and not some new concept.
What is new though is how interactions with the environment are changing and the rapid pace of that change. It is this pace of change which requires a larger role to be played by Business Architects. The biggest changes are with 1) customers, 2) business partners, and 3) the workforce.
With regards to customers, the importance of knowing your customer and listening to them hasn’t changed, rather, it’s the ability to gain immediate feedback and to also gain unsolicited feedback from them that is relatively new. In the past, organizations may have established small focus groups, conducted surveys by mail, or relied upon product registration cards to know their customers. We know the customer has always mattered, it’s just that now, the feedback loop needs to be continuous and instantaneous.
With regards to business partners, technology integration advancements have made it easier for organizations to establish partnerships that open the door to efficiencies and new business models. However, more partnerships will also lead to increased conflict and business model disruptions as organizations will generally be looking out for their own self-interests. The less an organization controls, the more disruption the organization will have to plan and be prepared for.
With regards to the workforce, the trend toward freelancing and bidding small pieces of work out will come with lots of legal preparedness and challenges around confidentiality and ownership (of the outputs and intellectual property). Also, the anytime/anywhere workforce comes with many challenges on measuring value and productivity. In both scenarios (freelancing/bidding and anytime/anywhere) it’s important to know what your expectations for value look like. If an organization cannot grasp that, then these new trends for engaging the labor force will likely not work out well.
Reflection 3: BUSINESS ARCHITECTURE: SETTING THE RECORD STRAIGHT
Business Architecture, at least to me, seems like an initiative which businesses engage in because they feel like they’re supposed to even though they don’t fully understand what it is. Because of this perception, I’ve chosen to reflect on the above article, as it attempts to clarify what business architecture is and what some of the misconceptions are.
The first point that caught my eye was the section entitled “Business Architecture: Where Does It Come From?”. The authors state that the business architecture should come from the business, which seems obvious on the surface. However, the authors point out that many times the business architecture comes from third-party consultants and from IT. Leveraging third-party consultants would indicate that the business does not want to dedicate their own resources to the initiative, which is a sign they don’t take it seriously and are doing it because they feel like they’re supposed to.
In the case of IT, I see a different dynamic at work. More often than not, I would expect that it is IT that brings the idea of a business architecture to the enterprise leadership. Also, more often than not, I would expect that it is IT that incubates the concept and gets it moving forward, as IT, while not possessing the same depth of knowledge of individual departments, often has the most breadth of knowledge in the business.
If a business can launch a Business Architecture program that is separate from IT, then that is certainly a good thing. However, if a Business Architecture program is launched by IT or IT is leveraged by the business, that isn’t necessarily a bad thing as long as the goal is to spin off this new competency from IT so that it can truly operate as a business-focused organization separate from IT.
The other interesting point comes from bullets #5 and #9 on the list of misconceptions. Bullet #5 debunks the notion that a business architecture is project or business unit specific. The takeaway is that the more narrowly defined the business architecture is, the less value it has. Couple that with bullet #9 which debunks the notion a business architecture isn’t needed because businesses already know who they are and what they do. The key word used in the debunking was “fragmented”. Business knowledge is very fragmented and there are very few employees with cross business unit knowledge and fewer still with a full enterprise perspective. If a narrow business architecture is of dubious value, then, to provide a business with knowledge it doesn’t already possess, the business architecture must truly be enterprise wide.
There are several other valuable points in this article that puts Business Architecture into better focus making it worth a full reading.
