Business Architecture requires executives to think differently. Unfortunately, there is still significant ambiguity
surrounding the job definition, tools, concepts, and frameworks - but most importantly value to the business. My 15 years experience in the various enterprise architecture roles have shaped my views, I have consistently used the techniques learned through enterprise architecture training, specifically around business architecture without having the job description
or the title.
What is a business architect's job? According
to Wikipedia, "A business
architect is a modern strategic business occupation. He or she practices
in the domain of business
architecture. Working
as a change agent with senior business stakeholders, the business architect plays a key
part in shaping and fostering continuous
improvement, business
transformation and innovation initiatives."
Forrester provides deeper insights. "Business architects must not only see the
big picture when looking across multiple process improvement initiatives, they
must also have business strategy talents, wide-ranging process discipline
skills in methodologies such as Lean and Six Sigma, and technology know-how.
Business architects have a rare combination of business domain knowledge, process
experience, transformation talents, methodology skills, and a winning
personality that helps with communication and business change management."
What does that mean? When I explain the role to someone outside the field, I
use the example of an interpreter or translator. A business architect
listens to business leaders, their visions and strategies, and interprets these inputs to develop artifacts that define IT capabilities and functionalities necessary to support the business needs.
By leveraging common nomenclature and a consistent approach to planning, IT teams are able to deliver on functional
requests while transforming from legacy applications and processes to new technology
and efficient solutions.
How can it make a difference in corporations? Individuals that can convert business strategy to conceptual technical solutions that serve business needs are few and far between. An architect must be able to SHOW the value with tangible business benefits; it cannot just be a series of documents or processes. In my experience, the best way
to show value is to take baby steps in some key areas that can benefit from the processes performed by a trained Business Architect.
In one of my last roles, when the IT Enterprise Project Office received a project
concept document from the business, the business architect added the business capability language
to the features section, showing the business team how their features and
functions would "roll up" to capabilities, bringing clarity to the business need. Then the business architect translated the business strategy to the necessary conceptual IT needs and the technical design went from that point forward to build.
As a
results, when the governance board reviewed projects, they were able to understand the artifacts to identify duplicated efforts in both architecture and applications because there was a line of site from business need to the technical solution.
Let's look at an address change: One of the most common and simplest capabilities. At one company where I worked, there were 18 separate applications and
many data tables that had to be updated any time an
address changed. Every change cost far more due to amount of technical and testing complexity.
The second company had 16 and when USPS added mandates and incentives incentives to validating addresses, the CEO
asked why an innocuous effort like this cost $3 million to resolve, and delivered ROI of over $8 million in the first year. The CIO explained the processes involved, then created a business architecture team that defined the necessary capabilities, and began creating artifacts that translated business processes to IT solutions.
Business Architects' perspectives is critical to building great solutions that meet the business strategy and can measurably prove the business benefit.
After
several stops along the way in several different positions in IT, I want to
return to EA as it is my passion and I want to do a job that I love.
Here is my
conundrum. The game's the same, but the names have changed. I am aware of the new solution architect
role and its involvement with implementation. The real problem is that as I
look for ways to apply my EA experience, the IT industry expects an unrealistic expectations of technical
knowledge. It used to be enough to understand
the technical concepts and high level implementation needs for the solution. Now the job descriptions require development and implement detailed knowledge in those technologies.
An architect and a technology expert are very different.
I have solid working knowledge of SOA, web services,
enterprise service bus, and integration techniques; however, I have not actually
written code in these areas. I understand the concepts and logical structures, but I
have never claimed to be an expert in the technical networking functions or IT operational functions (networks/hardware/infrastructure). The enterprise architecture role has moved more toward technical experts using technologies, and less about concepts and techniques to apply technology to a solution.
In my opinion this has blurred the lines between the the enterprise view and the implementation view. In many situations, it leads to a lack of governance and oversight, leading to architecture that doesn't solve the business problems.
The value of Enterprise Architects understanding the business capabilities and technical solutions across the enterprise is no longer valued. Instead, the new architecture positions are specific to technologies such as Cloud or Business Intelligence, instead of understanding that the "How" is not as crucial as defining the "What." There are always multiple ways to attack a problem: The real value comes in defining the goal and identifying obstacles to achieving it. Knowing specific technologies does not provide the framework to implement a sound, well architected solution where all the parts are well integrated and controlled for the enterprise.
This shift has limited the ability for trained Enterprise Architects with specific conceptual knowledge to find key roles in today's work place.
Any insights
would be greatly appreciated.
