OBASHI Think

See things clearly

O-I-B-I-A-I-S-I-H-I-I … a bit of a mouthful

I was posed an interesting question over the weekend.

 

The question was about OBASHI and Business and IT Alignment (BITA):

 

I wonder why you did not include the I of Information in your layers / method. Would you please be so kind to explain that to me?

 

I’d love to…

 

The alignment of information is seen by some as critical to BITA, and therefore the questioner would also seek to ask "Should the OBASHI methodology become the OB-I-ASHI methodology to show information between Business and Applications?"


When we created the OBASHI methodology we wanted it to be of benefit to everyone, regardless of their role in the organisation. Being tasked with B&IT alignment means that the structure and use of information passed between Applications and Business processes is where your analysis might take place.

 

However, if you are a network engineer tasked with reducing the latency in a bank’s trading system, the data (or information) passed between infrastructure devices will be where you want to focus your attention. For a programmer, the information and structures passed between software application interfaces will be critical to a successful implementation.

 

In fact, looking at the OBASHI methodology from all of these points of view you’d be hard pressed not to make a case for making it the O-I-B-I-A-I-S-I-H-I-I methodology. The analysis of information/data being passed between and within the layers is important to every domain expert … regardless of where their core competencies lie.

 

That’s why dataflow is so important, and why it is an integral part of the OBASHI methodology.

 

We use dataflow to show the interaction that takes place between, and within, the OBASHI layers. This forms a fundamental part of OBASHI, and is listed in The OBASHI Methodology as the first OBASHI Core Principle:

 

“The understanding of the flow of data is fundamental to an organization's financial well being”

 

Within the Laws of OBASHI, which govern the modelling and operations of the OBASHI methodology, Law No.9 states that "Any data type, or classification of data, can be attributed to a Digital Flow of data." This gives the ability to document exactly what information is passed between elements in as great a detail as the analysis dictates.

 

In the case of BITA we can start by mapping the current state of operations using B&IT diagrams, and then superimpose data flow to see the interactions for a more detailed analysis.


So should it become OB-I-ASHI? No. The flow of information, its structure and content is important at every layer, not just between Business and Application… why limit it to just Business and Applications?

 

O-I-B-I-A-I-S-I-H-I-I it is then, with information between every layer...well no, it's a bit of a mouthful.

 

Let’s stick to OBASHI...using dataflow helps keep things simple, yet powerful.


If you want to know more about OBASHI and how to use it, the manual is available here.



 

Views: 112

Comment by Machteld Meijer on August 31, 2010 at 13:05
Thank you very much for answering my question in your blog!!

Actually with the I of Information I do not mean an information or data flow. The I we include in the models is the I of the Information a business process needs. From the business point of view. Every business process needs information (of course administrative processes need relatively more Information than engineering processes). The other I’s you included (O-I-B-I-A-I-S-I-H-I-I) are absolutely not in line with the I I mean.

You write: "When we created the OBASHI methodology we wanted it to be of benefit to everyone, regardless of their role in the organisation. Being tasked with B&IT alignment means that the structure and use of information passed between Applications and Business processes is where your analysis might take place."

You are right, the analysis takes place somewhere between the business processes and the applications. But it is vital, crucial for a good B-IT-A. Therefore we recognize it as almost the most important step.

When the business doesn’t know which information they need in/for the business process or for controlling the business process, then the applications will not be built correctly and therefore not work correctly, no matter how excellent the SHI-layers are aligned. The outcomes of the IT (reports etc) will not meet the needs of the business process. Therefore the B-IT-A will be poor.

A very simple example: When I sell assurances I want to know how many I sell and how much profit I make in a certain time period (for instance). When the application tells me how much I have earned but it does not include in which period then the report and thus the application is of little value to me. Maybe the application developer did not include the period because I (the business) forgot to tell him that the information I needed was “profit / earnings per period, because I want to see trends”. Therefore the I is most important.

From other international contacts I also get the picture that the value of Information seems to be much more esteemed in the Netherlands than in other countries.

Anyway: I think the I in OBIASHI should be something you might consider again. But maybe there should be an agreement on the meaning of the term Information first.
Comment by Paul Wallis on August 31, 2010 at 21:27
Hi Machteld,

Glad to have you aboard OBASHI Think.

It’s an interesting debate which has taken place within the industry for many years, “What is data and what is information?”. Trying to get a definition which everyone can adopt and buy into is very difficult, and there is much ambiguity about its meaning.

However … I think what may be useful, here, is to outline a little of how I think OBASHI could help with BITA – and I’ll take it from the initial engagement.

Firstly, we need to understand the status quo – the current way the business works. OBASHI is a great way to capture this, and you don’t need to capture information from all of the layers. If required, you can just build a picture of the current business processes, broken down into sub-processes etc. to get as granular as you need. You can also capture the Owners – those people who deliver, and those people who use those processes. Finally we can map the applications used during the business process.

This gives a good place to start – a clear picture of what you have (the elements) and why you have it. We call the picture a Business and IT diagram (B&IT).

Now we have the B&IT diagrams, we can map the dataflow to create Dataflow Analysis Views (DAVs). This shows that interaction takes place between elements. In the above example, it could be interaction between business process elements, application elements, or between business and application elements.
If I understand you correctly, this is where the I of your information kicks in. At every point where interaction takes place between business and application elements in the dataflow, specific details about what constitutes the information can be documented. Not the information itself, but information about the information – how the data is made up, it’s structures, how it is transferred. How it is used can be documented as part of a business process element.

Within OBASHI, we have the concept of providers and consumers of data. The first node in a dataflow is a provider, and the last is a consumer. By adopting this we can document what information is provided, from where, in what format etc… and we can show how the data is consumed by an element. At the consumer you can document the full specification of what the information is, how it is presented and structured. Multiple providers can feed into a single consumer too – allowing an element to combine the information with which it has been provided.

So we end up with three distinct things which I believe are of significance:
1) What – the information is. The specification for the information interface between elements. In this case between Business and IT.
2) How - the information is used.
3) Why - the information is needed.

And it’s worth noting that although we’re discussing BITA, these three distinct points can be played out throughout the model at every layer.

The debate over what constitutes information vs meta-information purely depends on perspective and use, but when the What, How and Why are documented there is minimal ambiguity.

Hope that’s cleared things up…

PJW
Comment by Machteld Meijer on September 1, 2010 at 20:57
Hi Paul
Thanks for your reaction! I need some time to get back to you with a reaction from my side.
Machteld
Comment by Mark Smalley on September 5, 2010 at 10:41
Machteld invited me to take a look at this thread (deary me, what am I getting myself into this time?) and my main comment is in the form of the question whether (and how) you can use OBASHI to describe interaction and information flows between people executing business processes in organisations and other people in either the same or other organisations, but without necessarily making use of applications. Or is OBASHI mainly a model to describe the working of computer systems with the OB as 'just' a way of giving the systems a business context? Anyway, glad that I found some fellow thinkers ;-)
Comment by Paul Wallis on September 6, 2010 at 11:35
Hi Mark,

Glad to have you aboard OBASHI Think, and also glad you asked the question.

You don’t need to use all of the OBASHI layers in the framework. What we place on a Business and IT diagram, and the layers we use, depends on the intended use of that B&IT diagram – what we want to capture / show, and the intended audience for the B&IT.

If you want to map people in the organization and the business processes they execute, you can map them in the top two OB layers. OBASHI makes use of hierarchical elements within any of the layers. Hierarchical elements enable one element to be broken down into multiple constituent elements. This gives scope for organagram type structures in the Ownership layer, and a breakdown of high level processes into workflow within the business layer.

If you have other toolsets, methodologies or ways of working that already do this, it’s not a problem. OBASHI can act as a glue to bind these together and make the information more contextually cohesive.
Is OBASHI mainly a model to describe the working of computer systems with OB just giving business context? No.

Let’s look at it from both sides of the Business and IT divide. 1) The business guys could map the business layer or owner layer. 2) The IT techies and IT Managers can map out the IT. In fact, just the application guy or the network guy can map out their layer and not reference much in any other layer. Each will gain benefit from doing that and see their layer more clearly. However more benefit could be achieved by looking outside their layer too.

OBASHI’s concept of Relationship Persistence can bring order to any such chaotic scenario, as it enables these two camps to document and model the layers in their own area of expertise whilst, almost unknowingly, contributing to an overall model which pulls / ties the layers together.

So, the simple answer is Yes, you can use OBASHI to describe interaction and information flows between people executing business processes in organizations and other people in either the same or other organisations, without making use of applications.

Add more information about applications, even on a separate series of B&IT diagrams and you’ll get a more complete picture and be able to make much more informed decisions.
Comment by Machteld Meijer on September 6, 2010 at 12:10
I'm afraid I still don't get it. I hope Mark does.

Starting at the business (which everybody always should do):

I have a business process. Selling assurances for instance. Most important to me is : which information do I need to run my business process, which information should be stored in automated information systems and which information will be stored on paper only, which information do my stakeholders need, how can I get the proper information to the right people at the right time. When I know, e.g. how timely my information must be I can make more technical requirements as well. The business process owner should decide on which information he actually needs and all the other requirements.

When I have layed down all the functional and technical requirements I go to IT. They start to build applications or adjust ERP applications to my needs. Others might install new mainframes or servers or networks. They all work together (hopefully) in a project (where at least input and output criteria for every contributer are defined) and in the end I have a new information system that runs properly and provides me with the information I need. The IT is aligned very well with the business then.

I still don't understand where your layers come in exactly, and I still understand least of all why the I of Information is not present since it is the most important element. Is it entirely hidden within the B of Business?

You state:
"So we end up with three distinct things which I believe are of significance:
1) What – the information is. The specification for the information interface between elements. In this case between Business and IT.
2) How - the information is used.
3) Why - the information is needed"

This sounds good to me, but then "And it’s worth noting that although we’re discussing BITA, these three distinct points can be played out throughout the model at every layer" gives me very much doubt whether I understand OBASHI. Are you talking about the same Information as I do?

I am afraid I still don't get the picture. It sounds very much 'written from a technical point of view' to me.
Comment by STEVEN PEARSON on September 6, 2010 at 15:27
Hi Machteld

I wondered if you and Mark might be interested in our info pack, which should provide a little more clarity on the OBASHI big picture. I'm happy to email it out to you if that might help.

steven
Comment by Machteld Meijer on September 6, 2010 at 15:42
Hi Steven,

If you think it might help it is very welcome. If it is not too complicated (OBASHI for dummies :-) ) that might be the case. Can you find my e-mail adress in your data? Otherwise you can find it on www.maise.nl . Or send me a message.

I already received The OBASHI information Portfolio.pdf . That was the source of my questions.

Thank you in advance

Machteld
Comment by Paul Wallis on September 6, 2010 at 21:49
I think this comes down to a matter of perspective for whether OBASHI is written from a technical point of view.

If you are working at a technical level, such as in the lower layers of the OBASHI model then the type of information you will need to address is very much technical in nature. An example may be from an ITIL perspective where the information may be for creating Configuration Models. I understand that this is absolutely not the type of information you are meaning… but for the sake of completeness I mention it so as not to mislead.

From a business perspective the information is as you say, and not “technical” in nature – although I guess we must be aware that technical can have many meanings.

So is the information hidden within the B of Business? If we look purely at the B&IT diagram in isolation then I can see that you would think this is the case, but that is to not consider the associated Dataflow Analysis Views (DAVs) which are applied to the B&IT diagrams.

The DAVs primarily show the flow of (at the upper layers) information through the business. So having defined what the information is, you can see how it is used by each process, and therefore why each set of information is required, and by whom.

Of course it can be shown flowing round the servers and mainframes and ERP systems, together with what happens to it there, but you don’t need to show or even document these if not required for that purpose. Personally I think you are missing a trick if you don’t do this.

We wouldn’t recommend you isolate information from its context, and OBASHI isn’t designed to be just viewed as just the big picture in isolation. B&ITs & DAVs are complementary and are designed to be complementary.

It may help to think of the B&IT diagrams as documenting the structure of what exists, what it is, and where it is – physically or logically. The DAVs can then show how these things are joined together through the flow of information.

Let me give you an analogy from an industrial process perspective:

You run a chemical factory. You document every asset – each pump, valve, heater and compressor. You document every pipe which connects them and you know the physical design of the plant. You draw a picture of how it all fits together.

But behind each asset there is information about how that asset works, the specifications it must work to, and what happens if it works outside of those parameters. You also have design documents to say how the process works – what chemicals flow where, and the specifications of what those chemicals must comprise. This information is critical to how the factory operates.

We have taken a similar approach to OBASHI. With OBASHI the B&IT diagrams are the physical design, and the DAVs document the process flow. The layers help you organize and categorise the types of assets which are used.

Just as you hold operating requirement information about the chemical plant assets, you can do the same with OBASHI. Instead of dealing with chemicals, we’re looking at information and data.

So is OBASHI written from a technical point of view? The manual and accreditation have been developed with industry experts from PRINCE2, ITIL, P3O and MSP, but we’ve ensured it’s not difficult to learn and understand. The main feedback from those already trained is its simplicity and ease of understanding.

We do think that being technically accurate is important and the OBASHI framework will let you get technical and specific about how things work together. We think that’s important when we make business decisions.

Add a Comment

You need to be a member of OBASHI Think to add comments!

Join OBASHI Think

© 2017   Created by Fergus Cloughley.   Powered by

Badges  |  Report an Issue  |  Terms of Service