See things clearly

Just received and email from OBASHI



At OBASHI we believe that the role of IT is to manage the flow of data between business assets because if you can do that well you should be able to manage your business better. We’ve written a couple of posts recently which touch on that.



Isn't this missing the point? We call it IT because it's about Information. There are three legs to the implementation of business strategy, being Resource (Finance), Talent (HR) and Information (IT). Personally I strongly believe that the primary role of IT is to provide the information needs of the business in support of the implementation of strategy. In order to do that we may capture data to process it into information, we may automate and regulate process to improve productivity and reduce waste, we may shift data around, but in all respects the automation of business is secondary to the informing of business.


Am I wrong?



Views: 96

Reply to This

Replies to This Discussion

Hi Steve,


Given your strong belief that the primary role of IT is to provide the information needs of the business in support of the implementation strategy, I think we are basically on the same page.


I think that IT is there to support the business too.  If IT isn't doing that, it's role is meaningless and we should question why it is there.


But saying it is there to support the business is kind of a grandiose statement and quite meaningless... how does it actually do that?


It's my belief that the IT equipment (routers, applications, servers, cables etc) manage the flow of data (or information) between one part of the business and another. 


You are right that OBASHI will show how automation is being played out in an organisation, or can be adopted to make things quicker, reduce waste etc ... and for some people that's perfect.  But knowing where information originates and where it used by the business is one of the reasons we created the Dataflow Analysis View.


The data may get changed, refined or altered in some way (perhaps turning it into information) as it flows, but ultimately it is used by someone or something within the business to cause something to happen - to create a business effect.  And that effect "should" be inline with the business stategy.


For us, OBASHI is about getting sight of People, Process and Technology, how data flows through them and how financial attributes can be placed against them.  And I think this isn't far from your assertion that Resource, Talent and Information as being the three legs to implementation strategy.


If we look at the top 2 OBASHI layers, they are all about how people (Talent) are organised and used within a business.

If we look at the bottom 4 OBASHI layers and associated Dataflows, we can see how and why Information (IT) is deployed.

If we look at the financial attributes we see how Resource (Finance) is used.


So building an OBASHI model of part of a business (planned or existing) would allow you to see how well an implementation strategy is performing - allowing you to manage your business better.

Hope this puts a bit of context around the email.




Thanks Paul.


From my perspective what people need to keep in mind is that the primary purpose is to generate the information needed in an effective form with a timely delivery. The whole determination of data, systems, workflows etc. needs to be predicated on this objective, hence my concern each time I come across people interpreting the role as other than delivering the needed information. Essentially all IT systems can be measured by very simple metrics:


Do they deliver the information required when it's needed?

If not, what's the cost of under-delivery?

Do they do more than deliver the information required?

If so, what's the cost of excess-delivery?


The next layer down, the complexity of designing and delivering systems which provide the required information, is IT not business. It is complex, difficult, challenging, and often benefits from the support of formal methods to assist in the analysis and design of such systems, but if we lose sight of the desired product, information, at any point in the execution of method then we risk delivering systems which fail in their primary purpose. Therefore our method, whichever we use, should remain information-centric at all stages, and should express that repeatedly in aiding and guiding its users to deliver effective systems.


Ultimately measurement has to be based upon outcome, not process. Process is merely codification of a method to achieve outcome. The world is unfortunately littered with systems that execute process without achieving the desired outcome. Not having used OBASHI I can't comment as to whether it achieves better outcome than other methods, but I do caution that the purpose of IT is to achieve outcome, the management of process is entirely secondary, and I think we should always represent this when talking about our methods.


My 2d ;)


Cheers, Steve


© 2018   Created by Fergus Cloughley.   Powered by

Badges  |  Report an Issue  |  Terms of Service