Solving the Mythical Business to IT gap
By Greg Suddreth and Whynde Melaragno
The rise of Business Architecture can be directly attributed not only to the
continued failure to develop good Business Requirements (that
actually represent the business), but also to the change in the role of the Business Analyst. In 1995, the Standish group first published their CHAOS report. The report looked at the success and failure criteria of IT projects. In the 1995 report, it listed the top ten factors that caused projects to be challenged. The top three reasons all centered on the inability of the business to either properly engage in or properly communicate their requirements. Since that time, billions of dollars have been invested in developing a better Business Requirement. We have seen new methodologies created, countless books written and an assortment of Business Requirement tools developed. With all the investment and effort devoted to this space, requirements must be better today than they were in 1995, right? Yet, study after study still report that requirements is one of, if not the top, reason for the failure of IT projects. So, here we are more than 13 years later and the requirements problem is just as big, or bigger, than it was then. At this point, we have to ask ourselves if we are approaching this problem the right way. One of Albert Einstein’s most quoted statements is his definition of insanity, “The definition of insanity is doing the same thing over and over again and expecting different results.” Is that what we have been doing with requirements, trying to bridge that gap between business and IT by building better Business Requirements? The problem is not in the approach we are taking, but in the problem we are trying to solve.
We have all heard that there is a gap between the business and IT. The Business Requirement and the Business Analyst have been put into a position to fill that gap, but the more the Business Analyst tries to fill the gap by getting closer to IT, the larger the gap is becoming.
The Business Analyst used to be an individual who was an expert in what the business was and what it did. They could tell you every step in every Business Process, why it existed (i.e. what problem the business was trying to solve), and how the business was structured to deliver value. They were a member of the....
Using Business Architecture to Address Cross-Organizational Challenges
By Peter Blackwood
Imagine the following scenario: The Company, organized into three distinct product lines, sells a range of products, all to the same target customers, but each through different methods of distribution, with completely separate processes, and without any integration across product lines of supporting inventory, sales and customer information systems.
Feeling pressure from the company's board of directors to drive revenues and trim expenses, the CEO sets dramatically increased sales and profitability goals for each product line, and promises to achieve it through cross-product line integration, including a newly coordinated approach to product marketing, sales and distribution.
Although the leaders of each product line have always seen the opportunities that cross-selling would provide, previously none have been able to act effectively outside the boundaries of their own vertical organizations. The company has attempted to fix the product line "silo" problem before, but each attempt, led by mid-level managers from each product line, has failed to yield results, as each product line has clung tightly to its own incumbent distribution, sales, and customer information systems.
The goal is clear, but how does the Company break through the barriers that define its current operations?
An architectural approach, led by an independent team, with executive sponsorship, is the place to start.
Read Full Article
Using State Diagrams in Business Architecture
by Dr. Raj Ramesh
When process maps don’t work
A few weeks back I was working with a client to try to capture their business process in a process map. After a long time of trying to understand and map the process, and seemingly going around in circles, I realized that, for what we were creating, a process map was not the best type of model to use. What we actually needed was a State Diagram. As a team, we were working with the preconceived notion that we needed to create a process map. This is understandable, as process maps are so commonly used today in business architecture practices.
It’s easy to assume that the process map is always the best way (or only way) to model a business process. However, in some cases, when analyzing processes, a process map is not always the right tool for depicting what you are trying to see.
Business process artifacts, only one of which is a process map, are critical components of business architecture. Business processes are often modeled in process maps that accurately depict a sequence of activities. But what if the process under consideration cannot be elegantly represented in a sequential set of steps? That’s where a state diagram comes in handy.
The State Diagram Concept
The main components of a state diagram are events, states and transitions...
Read Full Article
Who Owns Business Architecture?
by Whynde Melaragno
The concept of Enterprise Architecture, which is comprised of Business Architecture, Application Architecture and Technical Architecture, first emerged within the IT community. As a result, there is a common misconception that IT should “own” the Business Architecture.
Unquestionably, the business should own the content represented within the Business Architecture. The content is exclusively about business subject matter and requires business direction and decision-making. However, the physical Business Architecture “blueprint” (e.g. models, frameworks, etc.) may be developed and maintained within either the business or IT department.
At first, the possibility that the Business Architecture may be maintained by the IT department may seem counterintuitive. Shouldn’t the business always own the Business Architecture?
Read Full Article
A disciplined approach to creating and maintaining a set of business-owned information assets that serve as a blueprint for the planning and execution of strategy.
•First and foremost, Business Architecture is developed by the business for the business.
Business Architecture provides a common, enterprise-level business language and framework for documenting how the business is structure.