Thursday, April 10, 2008

The Concept Of System Boundary

It is very fascinating to note the revolution of automation that the electronics and the IT industry have fostered over the past several decades. 

It is indeed true that one can go to any extent of modeling real world objects with increasing advances in the discipline of design and engineering as it evolved from structured and modular thinking to object orientation and further into a layer of abstraction called design patterns.

I am a true believer in this concept of systems thinking and an ardent subscriber of the ideologies of systematic decomposition of a problem statement to finer levels of granularity so that the design can scale up to NOT JUST solve the stated problem but also address, with minimal rework, un-stated problems that usually arise as usability issues while using the system to solve the stated problem. 

But I have simultaneously felt that there is sometimes a lack of moderation in the enthusiasm by some people to extol the ability of humans to model and then automate real world objects and their behavior into a package of hardware and software right up to the extent of building Cyborgs (or Cyber Organisms) that can mimic human behavior in totality.

Of course I am referring to some filmy depiction of the application of this form of the technology in films like Matrix, Terminator etc.

I used to wonder why I was not able to put my objection to this in words although something within me kept telling me that this is exaggeration of the highest magnitude. 


Some point was totally being missed in depicting the usage of technology to this level.

My pet hate topic in this industry has always been Artificial Intelligence as it always ends up being a case of 6 blind men defining an elephant. I feel almost everyone has their own opinion of how much artificial intelligence can actually be developed and demonstrated as a result of using electronics and supporting software for the same.


I really feel thankful for having read a very insightful article that elaborated on why we need various external consultants like a system's analyst or a business analyst in modeling a problem domain and to define it in a telling manner the author had beautifully used the concept of Artificial Intelligence in stressing this aspect. 


I am not able to recollect either the author or the journal that published the article and what remained imbibed in me were his defining views on this subject which I would like to share to everyone through this article.

The central theme of that article was the simple philosophy shown below

"You cannot be a part of what you define"
The key word is being able to "define" which should be understood as being equivalent to the meaning of a word as defined in dictionaries. 

Of course one can talk a lot about what one is a part of. Like how one can talk hours on end about one's own self. 

But to be able to define something is a totally different ball game and for the content to be end to end in scope and to be near perfection it always needs to come from a source external to it.

For example a storekeeper would never be able to define the inventory management system and can at best excel in providing his perspective of what he wants it to be and the same is true with all the stakeholders of the Inventory Management System. 

It really takes an external consultant or a modeling specialist to put all the pieces together to form a synergistic whole called the Inventory Management System.

To underline this theory of "The need for someone external to an entity to be able to model that entity in entirety" that author had used the domain of Artificial Intelligence.


The keyword in that domain, which misses many enthusiasts, is the very first word: - "Artificial". 


It has a significant meaning and means that whatever be the scope of human intelligence that is modeled by a specific AI implementation, say a robot in an assembly line or a unmanned aircraft for that matter, it can never ever be complete and replace human intelligence altogether in that field. 

Even if an intelligent framework is built to sense atmospheric parameters and take some decisions based on a combination of variables, somewhere it all boils down to a pre-programmed set of conditions being mapped against a clearly documented set of actions for which the software that drives its implementation is built for. 

In other words since the implementation can come only from a human being, however extra ordinary he is from a normal human being, the implementation cannot be more than his own complete intelligence which is naturally a subset of all of humanity's put together.

This was somehow my basic instinct in rejecting such concepts in films although the technical brilliance was overwhelming and then the moderation that it’s after all a film helped me enjoy the entertainment without further bias. 


After reading this article my instinct got the form of some words and also my perspective of System Boundary improved leaps and bounds. 

This blog is not about Artificial Intelligence anyway and in no way meant to trifle the advances made in the field of AI, as by itself it is a highly revolutionary field. 

Fuzzy logic based systems have enabled man to travel hitherto uncharted territories like sending an instrument to read the ocean floor, plot data to predict earthquakes, Tsunamis and so many other things that have enriched the existence of even the average human being.

An appreciation of the topic of system boundary has always stood me in good stead when bringing my interpretation to the table in day-to-day project discussions or proposal preparations especially when it comes to deciding what is within scope and what is outside the scope. 


The fundamental basis by which scoping can be done correctly is by deploying a sound understanding of what is the system boundary of the system we are currently analyzing. 

This understanding can also help us in correctly identifying the interfaces and the structure of each interface that the entity exposes to its outside world.

This concept comes in very handy in projects when a feature is being analyzed for the validations that one would do before initiating a process.


Typically an application is a sum total of Event-Response chains. 


Each process thread (say a Save action in a screen) is a series of event-response activities before it dies down with the first event being initiated from an entity (typically a human agency) sitting outside the system's boundary. The most immediate response by the system for an end user initiating event is typically a validation process before it can trigger the next event of lets say a database storing activity. 

The concept of system boundary is the most essential clarity required to analyze what is the scope of validations you can automate and what remains within the boundary of the end user to ensure for himself.

Let us take the example of a excel upload of data. 


If the application is expecting data in a particular format then one of the validations to put in place would definitely be various checks on the format compliance.

Now while it may be easy to check a few critical signature cells and decide that the format is valid or not, it will open a whole world of scenarios for the user friendliness of the error message if you consider all the invalid data input scenarios. 


For instance an end user may be uploading an excel sheet that is slightly out of sync with the format (say a spelling mistake in a cell having some key field) or may be uploading a file that is totally out of sync in content.

Let us assume that the functionality is such that by inspecting cell A1 of Sheet 1 to have a particular signature value for a downloaded template it might be enough to convey to the end user with a highly generic message that the input file is not as per format. 


Here is where the concept of boundary will come in deciding how far you would go in conveying how much away from the format compliance the input excel sheet is.

Any or all of the following validations may be included in scope, with exclusive messages that convey what exactly is wrong with that file
  1. Whether the file is an excel file at all (sometimes a word document can be renamed as an .xls and file filters in the OPEN FILE dialog may not always save your application from disgrace)
  2. The file may be an excel file and may totally be empty
  3. The file may have the data in the right format but in the second sheet while you expect the data in the first sheet
  4. There could be duplicate rows of data across the data region
  5. ...........
  6. .........
  7. ......
  8. ...
Actually there is no limit to the seemingly finite number of scenarios that you can check and give error messages and is only limited by creativity, project scope (i.e. how idiot-proof should your application behave) and most importantly budget. 

The concept of system boundary in this example can be understood as where the list of validations will stop and it naturally means that at that boundary (Artificial Intelligence), the system boundary of the end user (Pure Native Intelligence) takes over and he/she has to inspect what exactly could have gone wrong with this upload. 

The user may even be surprised to see that he tried to upload some weather data while the application was expecting some bulk upload of exchange rates !!

The above example may seem rudimentary but is only being used to convey the universality of the concept of "System Boundary” that equally applies to each granular process that is part of a "Response" in the Event-Response continuum that makes up a process thread in a system, the sum total of which makes up the overall System Boundary of the system.


The more deeper your appreciation of this concept the more scalable the system that you will spec, design, build & deploy.

Good luck.

Regards,
Mahesh

No comments:

Humility - An Introspection

I felt it was very important to jot down for myself and incidentally share with others a deep realization on Humility that I gained based...