Enterprise is the Data: Are Processes Overrated?

The first thing I noticed when started to transition some of my clients from UML to OWL Ontology Modelling was that there was no notation for process modelling. While since then I developed an approach to model process-related information, that revelation made me think about the importance of processes. I dare to say, in today’s enterprise, data are primary, processes are secondary.

I believe that our understanding of enterprise is moving into the fourth stage:

  • Stage 1: “Enterprise is the Structure”. We try to make an enterprise manageable by defining what silos it has, and what their responsibilities are.
  • Stage 2: “Enterprise is the Processes”. We are trying to make the enterprise defined. We realise that collaboration between the silos, that makes the enterprise work, is not captured. Furthermore, we realise that silos working to their separate objectives do not necessarily deliver optimal results. Therefor we believe that an enterprise is defined by its processes. We haven’t forgotten the structure which is referenced in the processes.
  • Stage 3: “Enterprise is the Services”. We are trying to make the enterprise agile. Processes, recorded on paper or in specialised software usually were hard to modify or for that matter understand. We decided to try to break enterprise into services that are accessed via specified interfaces. That will make processes small and directly executable.
  • Stage 4: “Enterprise is the Data”. We want to optimise the enterprise. The enterprise is seen as collection of data that are manipulated by the enterprise, with secondary data used to judge the enterprise’s performance. The Services are still there, however likely be defined as REST-type operations against that data. The Processes of course exist, however seen more as implementation details.

Consider an example. Say you run a courier business – deliver parcels and packages for clients etc. You can view that business as a bunch of processes – like the process of order fulfilment, the process of marketing etc. Then you can start looking for inefficiencies in those processes, you will need to decide what data to use.

The more direct approach would be to start with deciding what kind of data show the health and functioning of the business, like profit, customer number, customer base growth, customer acquisition cost, customer retention, delivery times. They say if you cannot measure, you cannot manage – so we start with our ability to measure.

Then you can look at primary operational data: delivery orders, customer data, workforce data etc. Your enterprise is effectively in the business of converting data into data. Orders data are converted into instructions to delivery drivers. As the drivers proceed along their routes, they also generate data. You can choose to make something of those data in real time, or process them overnight.

After the data are defined, you can proceed to decide on the business rules and the processes. However with the data defined as the primary artefacts, you have process optimisation built-in. Say you may have different processes to convert orders into delivery schedules and shipment schedules. So instead of “that is how our enterprise works” we say “let’s find a process that will minimise costs and risks”.

So where do you start?

The first step, as with any undertaking, is to identify demand and the stakeholders. If you just went through massive implementation of an COTS ERP and BPM solution and everyone is in anticipation of the brave new world that follows, it is hardly the right time. However if the executives are demanding more data and buy into the idea of a data-driven enterprise, that is the good time to start.

The second step is to start producing executive-level Information Model – I call it “Executive Information Model” or EIM. Traditional Data or Class modelling notations that are focused on parcels of values are not suitable – your executive audience has no time to argue about naming and values, and you will not be able to educated them about Fourth Normal Form, encapsulation etc.

The only way is to use Web Ontology Modelling (OWL) 2.0 that focuses on properties and classification rather than data parcels. The focus should be on the data that the enterprise leaders will use to determine the health of the enterprise the way “The Lean Startup” made the startups data-obsessed.

The next steps is to model the operational data in computation-independent way. That information should either be consolidated with Process Models – however for some organisations “Process as Data” modelling may be sufficient while been a much more manageable activity.

(as always, comments on how to improve the post are welcome. And if you want me to write more on the topic, like a series of tutorials or a book, please let me know)

Ian Falconer

Senior Technical Product Manager at Amazon

10 年

Data consistency is crucial but any compliant and efficient process will often suffice. Designing and implementing rigid processes is Taylorist thinking only suited to fixed algorithmic activities.

回复

Hi Alex, interesting post. Your description of working from KPIs to business rules mirrors the Federal Enterprise Architecture Framework (FEAF). You may want to look at adapting it to your vision. Regards, Rick

回复
Julie Choo

Product & Digital Transformation | Author & Creator of THE STRATEGYJOURNEY | Entrepreneur | Investor

10 年

I think process and data need to go together. One is useless without the other.

回复
Andrew Goodchild

Solutions Architect

10 年

If you cannot express state and process then I suspect your ontological formalism lacks expressive power.

回复

要查看或添加评论,请登录

Alex Jouravlev的更多文章

  • You have your Business Architecture. Do you use it?

    You have your Business Architecture. Do you use it?

    As a Consultant, I often ask prospective clients about Business Architecture. The usual answer is that someone already…

  • The True Face of Level 4 Process Mapping

    The True Face of Level 4 Process Mapping

    We need to have a serious conversation about Process Centricity vs Data Centricity in the face of Digital…

  • Agile, Simplified

    Agile, Simplified

    It doesn’t look like there is a good working definition of what constitutes Agile. The Agile Manifesto is supposed to…

    6 条评论
  • As-is Modelling, the Sweet Wasteland of Enterprise Architecture

    As-is Modelling, the Sweet Wasteland of Enterprise Architecture

    Enterprise Architecture is under attack. On one side, the Service Design people are “planning and organizing people…

    81 条评论
  • Agile Expectations Board

    Agile Expectations Board

    An Agile Expectations Board seeks to prevent an Agile project from successfully delivering Iterations on the way to…

  • Understanding Semantic and Property Graphs

    Understanding Semantic and Property Graphs

    Executive Summary As enterprises increasingly adopt Graph Databases, to better reflect the nature of the data, or as…

  • The Cost of the Right to be Different

    The Cost of the Right to be Different

    It is a high season for IT contracts here in Canberra, so the “Let the Hundred Flowers Bloom” anti-pattern is in full…

  • COTS or CRHMS? Understanding Full Stack of a Core Enterprise Software.

    COTS or CRHMS? Understanding Full Stack of a Core Enterprise Software.

    Commercial Off-the-shelf Software, or COTS, seems as, although expensive, a way to avoid risks and challenges…

    1 条评论
  • Some Inconvenient Thoughts about Architecture

    Some Inconvenient Thoughts about Architecture

    Enterprise Architecture should include Diagrams understood by the highest executive level to be useful. If you don’t…

  • Expect More Sparse Data

    Expect More Sparse Data

    One of the arguments for NoSQL Databases, along their ability to handle Big Data, is their ability to handle sparse…

    1 条评论