We (architects) keep telling people that every system in the enterprise has to have an owner. Yet, we rarely make the case strong enough, and, occasionally, end up with solutions that do not work. Alas, the concept of system ownership is somewhat obscure and not easily graspable by not only laymen, but fellow professionals as well. This is an attempt to write a simplest possible explanation of the matter.
Software is meaningless in itself. That may sound far-fetched, but you have to agree that figures on a computer screen mean something to a human operator not because of some inherent property of a software system. What software system can do is to store, retrieve and manipulate arbitrary symbols — it’s a symbolic engine (or syntactic device if you know what I mean). It just ‘happens’ that the symbols reflect the reality in a way that is meaningful to someone, in particular, to the user.
To give an illustration, let’s consider an inventory management system. The purpose of having one of such is, broadly speaking, to keep track of items in stock. When, say, a salesperson wants to check stock level, she is interested in real items in a real warehouse. However, the system doesn’t know anything about real items and warehouses, what it ‘knows’ is that there are pieces of structured information and commands coming from the outside that transform the information in some predefined way. Yet, the fact is that when a user looks on the screen, it shows an accurate indication of the number of real items sitting on a real shelf. What makes it happen is that there’s a process happening somewhere that ensures that a) for each real item there is an appropriately structured piece of information somewhere in the system describing the item; and b) whatever is happening with the item, the piece of information is transformed to reflect the events happening with the item in the outside world.
Important point is that the process doesn’t happen on its own. There is a senior manager somewhere above both sales and inventory people in the command hierarchy, typically CEO-equivalent as these functions are rather far apart. It all starts when the CEO devises a plan that involves the sales people knowing what inventory levels are. The motivation could vary, but perfectly sensible example would be the desire to improve customer satisfaction by not selling things that are out of stock. In other words, the CEO wants inventory people to serve the information on inventory level to sales people (in service-oriented paradigm we call it business service). She doesn’t care how exactly the information is served, but she makes someone among inventory people accountable for it and, ultimately, writes a cheque.
The appointed person, suppose it’s the Head of Inventory, now has to come up with a way to implement the business service and make it available to the user base (sales). Important thing is that since the CEO doesn’t care of the implementation, yet still holds Head of Inventory accountable, it is up to him now to decide how the service would work. No one else in the company can tell him what to do, even though, obviously, it’d be wise for him to consult with other stakeholders. This is the point when the Head of Inventory becomes the owner of the business service. Of course, it is not the same ownership relation as in case of owning a car or house, but it is very similar in the sense that nobody can command you what to do with your car even if there are strong opinions involved.
There are many ways to implement the business service, e.g. phone call, daily report delivered electronically or even printed on paper — you name it. However, there are many other people who want to know things about inventory and there are many other things inventory people are asked to do, so in these days it is almost a default option to implement an information system, in this case it is inventory management system. Note, this is the first time software systems, and IT in general, enter the scene. The system could feature a self-service front end or direct integration with another information system used by sales people, this is not important. What is important is that the inventory management system is now a part of business service implementation and the Head of Inventory is now accountable for the fact that information in the system is (sufficiently) accurate reflection of actual inventory levels.
Of course, the Head of Inventory is not doing it by himself. Instead, he makes some of the people within his team responsible for the fact the information in the system stays accurate when all the things involving inventory are taking place. Whether it completely automatic or there are lots of manual re-keying happening — doesn’t matter. What matters is that there is an agreement (or even a contract) between him and his consumers and he employs people responsible for meeting the contractual obligations. As a result, all the things happening in corporate warehouses end up being reflected in the information system that has been commissioned as a response to the mandate given to the Head of Inventory by the CEO. Whatever story figures on a screen tell users there is always someone in the Inventory team who is standing behind that story and, in one way or another, personally responsible for making sure the numbers stay true.
Certainly, good implementation of the system make the task easier by automatically applying rules upon cues coming from the outside and making the records changing in the same way as the items they represent, whilst bad implementation will always get it wrong and would require someone manually going in and synchronizing the representation with the reality. Usually there is a combination of both; however, it is important to understand that the rules that system applies are not substitutes for knowledge of the real world, but rather dull cause-and-effect chains which someone has to put into the system and then subsequently keep updated as the life brings in change, and its the system’s owner who needs the rules to be updated. Or not, if he chooses to, but that would automatically mean more synchronisation work for his people.
Enterprise Systems Engineering 