schultz@grebyn.com (Ronald Schultz) (02/07/90)
Many of you have expressed an interest in the concepts of Object-
Oriented Organization Analysis, but no one has yet come forward
and identified that they have attempted it.
The replies received to date fall into two categories. Some
replies asked:
o Why would one want to analyze an organization from an OO
perspective, since ER diagrams, data flow diagramming and
other structured analysis techniques more than adequately
cover this and;
while others asked:
o What could one learn from such an effort ?
In answering the first set of comments, some background appears
in order.
BACKGROUND
My particular interest was driven by determining how technology
could be used within my company to improve productivity. Since
we are a federal systems integrator, cost and productivity are
critical factors in remaining competitive. As in many such
efforts the user community wanted a picture of where they were,
what things could be, and how could they get there from here.
We attempted analysing the company from a functional perspective,
creating DFDs of the major activities. We even used a CASE tool!
But the users (Vice Presidents and Sr. Managers) were quick to
point out that:
1) functions do not occur in sequence, that their activities
were asynchronous and many functions executed concurrently,
and that DFDs did little to describe this;
2) that DFDs did not help pinpoint who or what executed a
function or help outline or point to what alternatives there
were to move functions around;
3) that DFDs were only a static picture of a very dynamic
environment;
4) that the DFD did not allow them to identify what services
impacted other services in terms of having an organization or
individual be responsive to the needs of the company. DFDs
were unresponsive to reporting 'service levels'.
Stated over and over again by management was "I need a modeling
environment that will allow me and my staff to simulate what is
happening currently, and play WHAT-IF for what could be."
Readings in OO literature often referred to 'modeling',
'simulation', and 'concurrency' as inhernet features of the
object-oriented paradigm, and based on some 'playing' with
Smalltalk we considered whether an object-oriented model of the
company was possible. We naively believed that:
1) It would be fairly simple to describe each organization
(even individual) in terms of attributes (instance variables)
and operations (methods)
2) That metaclasses would be valuable to describe global
concepts such as 'Employee' or 'Line Organization' and that
classes and inheritance would significantly simplify the model
development process.
3) That methods could be developed to track the service, or
response time, of an individual or organization.
4) That some primitive version control or source code control
system could be implemented to track changes made to the
corporate model, and that these changes could be extracted to
describe how someone 'got to Point B from Point A'.
5) That by implementing some form of multitasking or
concurrency control, we would be able to model the dynamics
of the company in a 'real time' environment.
6) That changes could be made to the model 'on the fly' to
identify the impact of the resultant change.
IMPLEMENTATION
As we pursued this we began to realize that the approach was more
reasonable, but that some form of framework was necessary to help
partition the model. We selected Zachman's Information System's
Architecture framework as a possible model since it was already
well known within our company due to its support by IBM.
Each cell of the model was populated with classes we considered
appropriate to the intent of that cell. From that point we built
methods to relate these classes and objects, and then began our
modeling of the company. The model was implemented in Smalltalk
V/286, and is still very primitive, but very useful. Our naivete
does not seem to have impacted our being able to produce
something useful.
CONCLUSIONS
The continuing results of the effort are:
o The effort provided new insights into how our company
works, how individuals and organizations interact, and
how these interactions can sometimes results in poor
service.
o The model itself is extremely flexible, easily modified,
and could be adapted to any other organization.
o As changes to the model are made, the changes are
recorded, thus providing a history of how to migrate from
one organization structure to another.
o The multitasking features of Smalltalk do provide for
creating a pseudo realtime model that realistically
displays the dynamics of the company.
o We have as of yet to implement the capability of changing
the model 'on the fly' but we see this as still doable.
We are constantly discovering new applications for the model.
But the original rationale for the model, identifying ways of
improving productivity, was fully supported. By looking at the
services provided, and who or what provides them, it is possible
to identify redundant services, or approaches to streamlining
services. Also, currently manual services can be approached with
an eye toward automation, but within the context of how important
the service is in relation to all other services within the
enterprise. We have seen many instances of something being
automated that was irrelevant in terms of the overall needs of
the company. The model helps identify such misdirected activity.
The model is also very 'senior management' friendly. We have had
much better success using this approach than with DFDs for
describing the need, or non-need, for automation in areas.
We consider the approach of OOOA a powerful activity, resulting
in a great deal of organization informatio useful at a senior
management level.
Anyone out there with any comments or suggestions ?
Ron Schultz
schultz@grebyn.com