Actionable Business Architecture – IBM, May 31 2010

spinabundantInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 4 χρόνια και 8 μήνες)

270 εμφανίσεις

July 25 2010

Actionable Business Architecture

May 31


Today we’re talking about Actionable Business Architecture, and our speakers are going to be
Kerrie Holley, and IBM Fellow and CTO of IBM’s Business Performance and Service Optimization
Center of
Excellence, as well as Sam Antoun, Chief Architect for Business Process Management.

And they’re going to talk about the three perspectives of Actionable Business Architecture: (i)
Strategy and Transformation, (ii) Business Process Management, and (iii)


Our agenda is as follows: We want to talk a little bit about business architecture, but most
importantly, what makes a Business Architecture “actionable”. Why have we coined that term?

I also want to have a discussion around s
ome of the challenges we see in Business Architecture.

And then lastly, Sam will engage us in a dialogue around how we actually initiate an actionable
Business Architecture, how do we actually make it real?



What we saw from the study, from the CEO’
s mouths themselves, is that we should expect
complexity to rise.

CEOs are expecting a very high
level of complexity. But worse, a lot of those CEOs are not
comfortable that they’re going to be able to deal with those complexities. However, we saw that

standout companies feel very comfortable complexity.



So that brings us to the heart of our dialog today. And that is, why is Business Architecture
important? It’s important for the reasons we heard from the CEOs, in terms of the factors
their business.

It’s also important because
business pressures are increasing, they’re compounding as IT
constraints are growing. The complexity is not getting easier.

Stated a little bit differently, one of trends that we’re seeing in the marketplace, and you see
this on slide 9, is that for a lot of organizations, they’re spending most of their IT dollars, most of
their IT budget, is being spent on running the business
, keeping the lights on, operations and
maintenance, contrasted to spending that money on innovation, on new innovations, on
changing the business. And that’s what you see
on slide 9.

… But the point of slide 9 is that organizations are trying to

get rapidly to that efficient model,
they want to be at that 60/40 ratio.


We know that there are a variety of approaches that organizations can take, a lot of levers that
must be pulled to increase the agility and intelligence around decision making.


Those levers are reflected in slide 11. They include Business Process Management,
they include
they include
Business Technology innovation,
and of course it
includes Service Orientation

and Optimization (SOA)

We’ve coined a cen
ter of excellence around
what we see as a converged opportunity around
Business Process Management and Service Orientation (SOA), not because we see those two as
being different or going away.
we see the holistic approach of combining them as creating
more powerful opportunities.

And, when you look at slide 11, we see Analytics, we see Strategy, we see Centers of Excellence,
we see Collaboration, real
time visibility. We see all of the levers as levers that we can approach
in a more holistic fashion, as

opposed to a siloed fashion. And of course, that’s where Business
Architecture is going to play a big role.


So on slide 12, what we’re saying about Business Architecture is that we do see the opportunity
for Business Architect to address several aspects and
several models. One of those models is a
Strategy Model, an Operating Model, and an IT Model.

But Busines
s Architecture defines and manages this valued relationship and interaction amongst
Strategy, Operating, and IT models.

As you see in this picture, it reflects the intersection of these
three models



Strategy Model

includes the Vision, the Miss
ion, the goals, policies, and
commitments that the enterprise wants to make real. It has the intent, the motivation.
It reflects the strategy. It represents the way various stakeholders in the business
intervene and direct the overall organization, around
their employees, their suppliers,
partnerships, customers. The Strategy Model has that value proposition.


Looking at the
Operating Model
, it’s an integrated view of the operating model of the
enterprise. It reflects a variety of views, capabilities, and co
mpetencies. It describes the
various boundaries in that model. And of course it reflects key performance indicators.


And of course we have the
IT model
, the Information Technology model, which of
course plays a role as well, and is connected to the rest of

these architectural
dimensions. The leverage of IT within the business and operations makes it a critical
aspect of the business architecture.


So we believe that a Business Architecture is made actionable by its design
, by its operations, by
holistic. “Holistic” says that we don’t take Strategy and Transformation, or Business
Process Management, or SOA and treat these as silos. Instead we treat them holistically, where
we have common approaches, common metrics, common access(?), common tools,
maybe even
tripping in those tools, where we allow the intent of strategy to reflect itself without a lot
of transformation downstream in Business Process Management and Service

We see BPM, we see SOA, and we see Strategy and T
ransformation as essential in making
Business Architecture actionable. “Actionable” in the sense that what’s reflected in the Strategy
Model actually realizes itself in the Operational Model, and of course is part of the IT model.


To drive this point ho
me further, if you look on slide 14, slide 14 says we do see this as a holistic
approach. But notice some of the subtleties of slide 14. If you look at the four arrows, you see
Methods, you see Metrics, you see Models, and you see Tools. We see those four
aspects as
being critical to an Ac
tionable Business Architecture.

That is we must have
, we must have “holistic” methods, methods that address the
synergy between Strategy, Business Process Management, and development.

We must have
. Metrics
about whether, when we do a process, our we doing it better
than others in retail, are we doing it the same as others in Transportation or Telecom? Do we
know what the benchmark data is that tells us that a process should take 7 days, or 3 hours,
or 2
s? So, key performance indicators.

Do we have agility indicators

that tell us our ability to change that process or that operation, in a
matter of weeks or days, that is commensurate with what should happen, and what other
organizations that are standout p
erformers are doing? Do we have the right goals? Do we have
measurable goals? That’s what metrics are about.

And of course,

says that we actually have models that reflect our strategy, that reflect
the components

we call this a Component Business
Model. But also Process Models. Not
Process Models that are drawings, but Process Models that reflect the actual animation of our
process, that allows us to do a simulation, that allows us to do predictive type of work.

Do we have the right Information and

Service Models? And, most importantly, do these four
models inter
relate? Have we built them in a holistic fashion, such that we can see from our
Strategy Models the actual Processes that we have, the Services that are used to animate those
processes, the

information that’s used to populate?


Do we also have the right

to actually support what I just articulated?
Do we have the right
modeling tools to model our strategy, to model our process, to model our services, to model our
information? So the mess
age on slide 14 is that we firmly believe, and this is where a lot of our
research is headed within IBM, is that we believe that the intersection of these areas of
Strategy, of Business Process Management and SOA, affords us a significant opportunity to
ke Business Architecture actionable.

And we do that with the interlock of these four things: methods,
models, and tools.

so that says
we have to have assets of these kind, to
enable us to close this gap so that
there’s less transformation
, as we move from Strategy to downstream activity, as we move from
Strategy to Operations, as we move from Strategy to IT implementation.

So that’s the message on slide 14, is that a holistic approach around Architecture, around
Business Architecture, prov
ides us some significant opportunities to make it actionable, and
“actionable” translates to faster time to value, and faster time to market.

And so what I’d like to cover next is what are some of the challenges of Business Architecture


The challenges

around Business Architecture are interesting. And first I think one of the big
challenges we have is around what is it? What do we call it? The fact that there are so many
parties in our marketplace and standard bodies that are defining Business Architect
differently tells us that we have a challenge just agreeing on what Business Architecture is
, and
what are the challenges.

So you can see on slide 16 some of the definitions that are from the Object Management Group
and the TOGAG group. But the point i
s we’re still struggling to deliver on its promise. And the
question is why?


Some of those answers lie in the roots of Business Architecture
, and for many of you, you know
those roots for a lot of people lie in Enterprise Architecture. And some have a po
int of view that
Business Architecture is solely a part of the Enterprise Architecture.


And if that’s true, is it good enough? And addressing Business Architecture as a part of
traditional IT Enterprise Architecture can be problematic. It can be problema
tic for a number of


Enterprise Architecture, for many organizations, is perceived as a pure IT endeavour, a
pure IT play. That is, many business stakeholders don’t see the connection, the tie
the value proposition of EA.

Some of that is becaus
e of how EA is realized and implemented. Some of that is because
of sponsorship. And some of it is because

, in our view, the lack of an “actionable”
business architecture, the lack of t

and connecting the dots to the Enterprise
Architecture, to the
Business Strategy

Developers of Business Architecture, in a lot of organizations, often have more IT
expertise than they do business expertise. That is, they are IT professionals

that’s their
origin, that’s their genesis. Business Architecture is conside
red, in some organizations,
just a stepping stone toward developing the IT Architecture. It’s not considered
something in and of itself that the business must actually buy into, and have an active
role to play.

And so this lack of participation



stakeholders in the Enterprise Architecture
minimizes the effectiveness of the
actual business architecture. These are some of the
challenges we see in status quo.


So the reality of owning the Business Architecture, which you see on slide 19, does cente
around this debate of who owns the Business Architecture? Is it owned by IT, is it a Business
discipline, is it an IT discipline?

Well, I think ideally the answer is that it’s both. That the Business should own the content and
relevancy. While the
development and maintenance of specific artifacts will be a responsibility
of the organization of the experts who have the most expertise in that area.

Some artifacts will be properly owned by people with an IT background. And BTW, the fact that
someone li
ves within the IT organization, or the business side of the organization, is not the
issue. The issue is the role that you’re playing in terms of the enterprise or the organization. And
stated differently, when we talk about the “responsibility”, the respo
nsibility we’re talking about
is a responsibility to have ownership of the business strategy and direction, and codify and
reflect that in a business architecture, such that there is this holistic alignment between the
three models I illustrated previously
: the Operating model, the Strategy model, and the IT

So that’s some of our challenges.


So, Enterprise Architects are going to be challenged

you see that on slide 20. They’re going to
be challenged to provide relevancy, and to make sure that Ent
erprise Architectures do have a
connection and relevancy to the business. And making this leap from a technology
centric to a
centric architecture may very well be one of the biggest challenges that Enterprise
Architecture face.

But independent of

that challenge, the point of this dialogue is to illustrate that Business
Architecture does require a voice. It’s not something that, I think, should be solely considered an
isolated part of an Enterprise Architecture, but something as an “actionable” Bus
Architecture, that should stand outside and of course still be connected.


So, you see that on slide 21, that the better incorporation of Business Architecture within
Enterprise Architecture is reflected in the slide and
picture you see on slide 21,

where these 3

the Strategy model, the Operating model, and the IT model

their intersection is, in
effect, this Business Architecture.

And it’s made “actionable” by the 3 things we do on the right, because


Because businesses are constantly in
a Strategy formation, execution, implementation,
and transformational role


Business Process Management

whether that’s a human
centric process or a very
heavy system
system, straight
through process


And of course Service Orientation

We think the 3 of t
hese activities are key and significant in making the Business Architecture


And, you know, what is it if we don’t have an Enterprise Architecture? And you see that the
Actionable Business Architecture can be developed, can be implemented
independently of
traditional EA activities. Because some organizations, let’s face it, don’t have EA programs. Some
have immature EA programs. And for still others, EA is purely, solely an IT initiative.

So those are obvious examples, obvious situations wh
ere Actionable Business Architecture can
be implemented, can be realized, and be of value to the business independently of what’s been
done to date.

So with that, I’ve concluded my dialog, and hopefully I’ve addressed the issues of what is an
Actionable Business Architecture. And with that, I’m going to turn it over to my colleague Sam
to discuss the whole issues around initiating a Actionable B
usiness Architecture.



So, the next few slides we’re going to talk about how we’re going to initiate a Business
Architecture, how to get started, how to realize the value of Business Architecture.

So what is really the value that Business Architecture
brings to the table that Kerry just
articulated? The real value is that we’re able to link the Business Strategy to the Operating
Model to the IT Model, and have a holistic view from the Business Strategy into Operations into

So with a well
formed Busi
ness Architecture, we’re can create this tight bonding between the
key domains of Business Architecture, and ultimately also down to the Application
Infrastructure. What that allows us to do is, if there’s a change in business strategy

example, if a
strategic objective has changed

how do we implement that in the operating
model and the process model, and ultimately the IT model?

Business Architecture allows us to have this agility, and implement this change in strategy
quickly, effectively, and eff
iciently. Whereas in the past, if we’d done these different approaches

Strategy, BPM, or SOA

in silos, we wouldn’t have that efficiency in implementing these
changes, and we won’t have this kind of agility.

So like I said, with Business Architecture
we can drive the linkages into the Strategy domain. In
previous eras, basically, companies

used to

do BPM,
, in isolation of
what’s going on in
the business strategy.

So they would focus on some process areas that are
not necessarily
linked to strategic objectives or the business strategy.

With Business Architecture, since we have a component model that describes the business, and
we’re able to link the business processes to these components, we were able now to trace the
value from BP
M upwards to business strategy.


On top of that, if we use Business Architecture effectively, we’re able also to trace value from
the Service
Oriented Architecture layer into the Process layer, into the Strategy layer. So when
we implement an IT project, we

can clearly measure its value, and measure how well it is aligned
with the strategic objectives of the business. Because at the end of the day, any IT project or
solution that is being delivered has to show value, the business has to realize the value out

such a solution.

So, Actionable Business Architecture, as I mentioned, directly aligns to and supports the
concepts of business performance and service optimization initiatives we launch across IBM. It
basically allows us to trace value from Strategy

to Operations to IT using Component Business
Models, Process Models, IT Models, and Information Models in a holistic approach, as Kerry
articulated previously.

And with the methodology, the tooling, and all the metrics we have in place to

istic approach, agility can be achieved. For example, how many times do you see in
organizations today that a change in business environment occurs, or a strategic objective
comes into play, and now we need
to make that

a reality into the business processe
s, change
business processes, or
build a new application?

Or, for instance, the new regulations that are coming down in the different industries

banking industries, the insurance industries, airlines industries, etc. Many of these clients, for
e, to comply with regulations, they are struggling really to identify which systems, which
solutions, or which process areas are impacted by such regulation

because a lot of these
solutions that they might have delivered in the past are not interconnecte
d, there is no
traceability to understand where a business objective falls into the process area, and which
applications are impacted.


With an Actionable Business Architecture, it becomes efficient and effective to implement such
regulations, because now w
e have full visibility from Strategy, to the Business Processes, to the
underlying IT Services implementing these processes.

OK, how do we make this “actionable”?

At the Strategy layer, we can get started by breaking
down our business in “components”,

“componentize” our business, and break down the
different Capabilities of our business into Components. We come up with what’s called a
Component Business Model

basically, at a very high level, componentizing the different
activities that our business c

A component would have activities, it would have the resources necessary to deliver these
capabilities, it would have all the different Services needed to deliver, etc. etc.

and that’s all
from a business perspective.

The next step, is now we
do the process identification and process modeling

which is a little
bit intersecting with the BPM layer. And as we all know, BPM is much more than process
modeling obviously. But process modeling is a key area, or an entry point, into this whole

where we now identify the core processes, we tie them into the business
components we’ve identified, and we align them with these components. In many cases, a
business process can stretch across multiple business components in the business, which is fi

And the next step, what we do is we build what’s called a Service Model to now connect to the
Process model, and how we’re going to implement the Process Model. And what that gives us,
really, is this end
end full visibility, from Business Strategy
into the Processes into the Services
that are going to make these processes real.


And that’s really the power of Business Architecture. And we’re able to incorporate any changes
that might come across in any of those three layers.

OK, so in this slide you see this full traceability I was talking about. So at the Business Strategy
layer, you
where we define our strategic business objectives, Capability Maps, business
strategy summary.

From that, we flow down into the Business

Processes. What are the business processes
necessary to make this strategy real? What are processes that we need to focus on that are core
to our business, that are going to differentiate us, and how do we make those processes real,
how do we implement
em using


The next layer down, as you see, to implement these processes, and to gain the agility that we
want, we want to use Service
Oriented Architecture to implement those processes, versus other
types of implementation approaches, legacy approaches

or other approaches. Because with
Oriented Architecture, we have the flexibility to build Services on the fly, we have the
ability to compose our business processes from discrete services.

We can compose processes using other processes, basically
allowing us to reuse what we’ve
built in the past. So as far as efficiency, such an approach allows us really to take advantage of
previous applications
we’ve built, leverage existing applications that we might have today, to
build new solutions


And the v
alue really that this is bringing to the table is this whole “traceability”. You can see we
can trace down to an object layer, a Java object or any object in the IT layer. And with that
traceability, if we have, for example, like I mentioned if we have a l
egal act coming in that a
system needs to implement, now we can see exactly which systems, which applications, which
services, which objects such a change is going to impact.

And by externalizing all of our business rules from the business processes, the b
usiness should
be able to efficiently implement such changes, because now they would own the policies, the
business rules, that

drive a lot of the business processes.

So OK, how do we make this real now? What are some of the outputs we need to produ
ce, and
some of the tools we need to use?

So like I mentioned, the first key output that we need to produce is a
Component Business
Model, or a CBM map, as well see on slide 29 at the top portion of the slide.

Once we have a CBM map, we can identify which
components are critical to our business, are
differentiating our business, and we produce this CDM map with our tool that’s called the CBM
Modeling Tool that we have in IBM. That tool basically helps us to model the business and
produce this Component Busi
ness Model.

And this tool actually plays very nicely with our WebSphere Business Modeling tool where we
can now, from WBM, link the Component Business Model map, and basically start linking those
into the different process when we do Process Modeling.

So n
ow we’ve linked the Component Business Model to the Process Model, and the next step is
we have a tool in IBM that’s called the SOMA Modeling Environment, or SOMA ME tool, that is

basically also a plug
in that we can leverage to do Service modeling

to mo
del all the Services
necessary to implement the Business Processes we’ve just defined. And with this round
approach that Kerrie mentioned previously, we’re able to basically connect these three models
holistically, we’re able to trace different po
rtions of these models holistically.

And of course, we don’t want to forget the Information Models. So information obviously is
important here, and we can produce Information Models in many different tools that integrate
into this whole end
end approach

So, just to recap what’s on this slide, the key components of a Actionable Business Architecture
are four artifacts:


The Component Business Model


The Process Model


The Service Model


The Information Model

And if all these models are developed in a
holistic approach, in cohesion

and we’ve taken into
account the different implications of one model into another

we realize the maximum value
from a Business Architecture.

So how do we get started? As I mentioned before, there are many ways to get st
arted. We could
start at the BPM layer

pick a couple of process areas that we basically want to enhance. We
can always start small and incrementally build upon different processes areas.

By no means, we’re not advocating here that we need to “boil the oc
ean” or do a multi
planning approach before we make this Business Architecture “actionable”. Exactly the

opposite. We can start small, start incrementally, and we can start from a process area like I
mentioned, or maybe start with an IT project that w
e want to enhance.

But the key here is, when we take the business process that we want to deploy, or the business
process solution we want to deploy, we want to make sure it’s linked to the Strategy Model. We
want to make sure that this BPM solution is lin
ked to the strategy objectives. That’s the key,
versus just doing a particular BPM solution in isolation of what’s going on in the business
strategy, and in isolation of what’s going on in the IT layer.

We can always start, liked I mentioned, by doing an S
OA project, where we’re building a
reusable Service across the organization to automate particular processes. But we have to be
careful that such an initiative needs to be tied to the Process Model, to the processes, and to
the Component Model, so that we
have the holistic approach, and we don’t repeat things
downstream that we [don’t ignore any] blind spots that might occur in any IT or process or BPM

So OK, getting started with breaking down the business into components. What you see on slide
1 is a very quick way to get started to break down the business into components using
Component Business Modeling and the Component Business Modeling tool we have from IBM.

That would be a good way to start: prioritize initiatives, produce a holistic view
of the business
represented as Components. And by doing a Component Business Modeling type of activity, we
can also prioritize what initiatives we want to focus on

which initiatives are most important


and we can produce a roadmap that will allow us to
implement the BPM projects or SOA
projects that we want to implement to drive business value.

So Component Business Modeling is one good, easy approach to get started on this. Like I
mentioned, we can get started from a BPM perspective or a SOA perspective

also. But from a
CBM perspective, we can engage the business, engage the line of business, and help get a full
understanding of the capabilities of the business, and start mapping out what’s important and
what solutions we need to be focusing on.

what is the best way to launch a Business Architecture journey? Each organization is
different, each organization has its own culture, preference on how to get started. So an
effective adoption of change and perspective, practices will be unique for every

The best approach for an individual organization is to initiate and start populating their actual
Business Architecture by addressing some of the questions that you see at the bottom of slide

For instance, does the organization delegate o
wnership and funding down to a division level, or
a line of business level? Who controls the funding? Is it the line of business
, is it different LOBs,
etc. etc. Does the organization have an active and capable Enterprise Architecture, and
Enterprise Archi
tects to get started? So there’s many ways to look at this through different


So on slide 33, different ways we can get started. We can take the four different entry points

vertical, horizontal, opportunistic, and enterprise.

So opportunistic, l
et’s start with that. We look at, maybe,
projects that are critical that we need
to do as soon as possible, and where we see opportunity to realize value quickly. For instance,
we focus on a particular process area, automating or deploying a particular
process area. We
can take that opportunity, model the processes, use a BPM solution to deploy and show value
immediate to the business in a very quick time frame.

We can start if we like horizontally, across lines of business and different departments. I m
there are many ways we can enter this. But the key here is we need to start small, show value
very quickly, rather than do any planning approaches, or approaches that will span many
months or many years. We want to show value to the business immediate
ly, that is the key.
Whatever approach we take, we need to realize value in two, three, four months duration, so
we gain adoption, and we move to the next solution set.


So OK. Now how do we get started with all this? How do we know where we’re at? How do

know, how do we measure across multiple capabilities? How do we compare to other
organizations in the same space? How do we compare to our peers in the business?

What we’ve done is we’ve developed
what we call the Business
Agility Model.
This flows bac
k to
slide 7 that Kerrie articulated in the beginning of the discussion, around the agility levers that
will drive different capabilities across the organization.

So with the Agility Model that we’ve developed, we can assess a current state of business agi
We can understand where an organization wants to go. So using this model organizations will be
able to assess their current state, understand where they want to go and how to get there

what are the actions they need to take to advance from the diff
erent levels: Level 1, Level 2, etc

So what you see on slide 34, on as very high level, is this Agility Model that we’ve developed. At
the very basic level, Level 1, we have a siloed, reactive, and rigid business, that is not capable of
handling changes e

we have siloed applications, business processes aren’t
documented, information management is not well understood, there’s no governance structure,
etc. etc.

At the top end of the spectrum however, Level 5, at the Agile level, we have a highly
and knowative, and agile business capable of handling unpredicted market changes. And that’s
the end state, the nirvana state, where a lot of our clients or organizations would like to get.


And always, in between, you have Levels 2, 3, and 4.
So this Agility Model is a good tool to
assess where organizations are today in terms of business agility, and understand where they
want to go and how to get there.

The next slide, slide 35,
basically shows us the different domains or focus areas that t
his Agility
Model covers. And as you can see, it covers a lot of ground, it’s not just technology. This model
covers many, many other business capabilities.

So the seven domains of this model are:


Strategic Convergence




Organization and Culture


Visibility and Control


Business Technology


Information Analytics


Business Process

Those would be the seven models. But we go down to a depth of level in these models that
assess the current state in each of the capabilities underlying these models. And we
come up
with a scoring using our tooling

in IBM we have what we call a Capability Assessment tool, or

the CAT tool, that allows us to perform this assessment, talk to the different executives in the
company, different resources, and collecting that data
and articulating a current state.

And when we do this assessment, we also understand where organizations want to go, based on
their current maturity level. And at the end we produce two key outputs out of this whole
business agility assessment.


Number one
is a diagnostic report showing the current state where organizations our at


And most importantly a roadmap

how to get to the desired level, how to achieve
those additional capabilities that we want, with actionable recommendations

And that’s the value of

this model we bring to bear here.

Next slide, slide 36, shows a quick, high
level summary of this model, or an output, that we use.
So basically you see the levels, levels 1 through 5, and then the seven different domains going
down vertically.

The red
dots represent current state. So if we do an assessment of a particular organization, the
red dots probably will represent where the current organization is in terms of these particular
domains and capabilities.

The green dots
represent where this organiza
tion wants to go. Some

not all the time

want to go to a Level 5, for example.

And the key about this model is that it is tied directly to business outcomes. Unlike other CMMI
models out there, this model is directly tied to business outco
mes. In other words, and
executive looking at this model that says “OK, I’m at level 2, and I want to go to level 5 in this

particular domain.” OK, what is the value realized? What’s in it financially? How do I realize this
value? What are the outcomes?

is model clearly articulates these business outcomes and results by advancing levels, unlike
other models that do exist out there today. And we have a light version of this model that can
be done fairly quickly, perhaps in a ½ day or a few hours. And there
’s a full version of this model,
that we do in an in
depth engagement over a two or three week duration, that produces a very
detailed roadmap on how to advance in the various detailed capabilities.