5. Information systems use of business language analysis

strict warning: Only variables should be passed by reference in /home/enterpri/public_html/modules/book/book.module on line 560.

The models of terminology produced by business language analysis have a central role in many key activities throughout the information systems development environment.  This starts with an understanding of the nature of the information systems development process itself.  Popular lifecycle descriptions (waterfall, spiral, etc.) give the impression that building enterprise class information systems is a downhill effort, somehow aided by gravity or some other natural force.  If business and business environments were static, this might be the case.  In fact, just the opposite is true - it is an uphill struggle against the forces of entropy.

A method that is grounded in the specific information access and communication needs of the human activity system, and is also informed by powerful concepts from general systems theory, linguistics, and cognitive science, provides some hope of winning this struggle.  This article recognizes information systems as serving systems for living organizations.  This point of view challenges the application-oriented and project-oriented approach to information systems, and affects many information systems functions.

Planning ¬– We can start with the planning function.  The living systems viewpoint lays the groundwork for a new perspective on planning the evolution of the nervous system of the organization.  The planning function will understand that it is not enough to provide disjoint inventory management,  order processing, billing, and accounting systems, with decision support systems coming along as an afterthought.  All of these must be present, and coordinated.  There must be visibility into information that is generated beyond the boundary of the enterprise itself.  The planning process should search for areas of isolated or missing information capability, and budget for work to address them.  It can use existing language models to determine the completeness of coverage, and may commission additional language modeling to fill in the gaps.

Architecture ¬– Architecture now also takes on a different meaning.  If the goal is to support the overall communication capability of the business as a living system, then architecture begins to look like putting an infrastructure in place that will support the organization’s needs for normative and long-term decision-making, and not just the standard operational and control functions.  By means of understanding the interactions among individuals and organizations performing roles within the domain, application architects can gain a better, more effective, understanding of the business functions to be supported.  An architecture based on cooperating agents will change the whole notion of business applications.  Detailed understanding of the language and concepts of the enterprise gives strong guidance to the types of software agents that need to put in place to realize its adaptive goals.

Project management ¬– Business language analysis must be managed as carefully as any other analysis effort, through continuing dialog between language analysts and project management.  It is often attractive to follow threads of language into areas that can expand the scope of projects in an uncontrolled manner.  On the other hand, language analysis can lead to expansion of scope that is appropriate, and may have been overlooked without this analysis.  A language model provides a means to reach agreement, in terms familiar to the user, on which functions, roles, and resources will be in or out of scope of a particular project.

Business language analysis provides strong support for the process of team building.  The focus on business language prepares the ground for many other development activities by unfreezing the techno-speak that many team members may use.  The process of analyzing business language helps to mediate among many different communities:  executive to line management, various functional organizations, supervisors to users, I.S. personnel to non-I.S. personnel, and even company to company, in the case of cooperative or consortium efforts.  It also lays a foundation for training in new procedures and system support.

Design¬ ¬– Business language analysis does not replace system design.  Business language analysis is a discovery activity that helps to understand information needs within the human activity sys-tem.  Design is a creative activity that uses language models as input.  “The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. ... While superficially appealing, this approach is seriously flawed.  It should be clear to anyone that models of the world are completely different from models of software.  The world does not con-sist of objects sending each other messages, and we would be seriously mesmerised by object jargon to believe that it does.”

A domain object model is a design of the business objects within an implementation.  Business objects are generally distinguished from purely technical objects such as GUI frameworks and data broker middleware.  There are several techniques that guide designers in making the transition from modeled language to an object perspective:
     • The generic concept framework provides a first-cut set of classes, subclasses, and
          collaborations that can be assumed to exist in some form in almost any domain.
     • Terms that map to the same high-level ontological concept should be considered for
          possible subclassing, or parameterization of a generic class.
     • Terms that are made up of a basic term and modifiers can be considered for hierarchy or
          variable constructs, depending on whether the modifiers indicate strong typing or state
     • Predominance of terms in one concept or another reveal or confirm the nature
          of the overall system to be built.  Predominance of resource-oriented terms reveals an
          inventory type of system, while predominance of role and process terms indicates a
          work-flow orientation.

The language model can also contribute to database design.  Database design issues are very similar to the set of concerns that leads to an effective domain object model.  In particular, if an object-oriented DBMS is to be used, these sets of concerns are highly convergent.  If relational technology is to be used, the techniques noted above will need to be mapped onto to an entity, attribute, foreign key paradigm.

Business language analysis has a special relationship with use case modeling.  Use cases have long been associated with the idea of a concept catalog or glossary.  This listing of terms and concepts from the business domain has been an important communication mechanism for project teams and the user community.  Business language analysis elaborates on the notion of a concept catalog, turning it into a model in its own right.  In return, the process of building use cases of how the system will be used in the new environment becomes a rich source of terms and concepts that may not have been previously discovered in documents.  Part of the reason for this is that these new terms may reflect a future scenario which has not otherwise been well documented by the business.

Clearly, other types of models beyond language models are required for effective systems design.  For example, event and traffic metrics feed the physical design of systems.

Development ¬– Given that information systems development is an ongoing effort to create a sys-temic capability, it is accomplished in stages, but always with an eye on the overarching needs of the organization as a whole.  Language analysis benefits each increment that is delivered, based on the ability to reuse term and concept patterns as powerful abstractions.  This results in stronger, previously tested code, and a shorter development life-cycle.  The benefit to the development process as a whole is traceability - establishment and maintenance of linkage between project artifacts and their business sources of justification.

A business language model provides key support for the development of user interfaces.  Terms from the natural domain language can be brought to the surface of the interface, where they provide a feeling of familiarity for system users.  Underlying code can be wrapped in alternative terminology for different communities of users, and can be evolved as the language of the busi-ness evolves. 

The information system to support an enterprise is never complete.  The application perspective regards this phenomenon as a problem that gives rise to a separate maintenance functions.  In contrast, the living systems viewpoint recognizes this as natural evolution.  Developers in the next incremental project have an established nucleus of defined and understood business terminology and meaning from which to expand seamlessly into new areas of the business.

Testing ¬– There are a number of issues involved testing software, including functionality, usabil-ity, accuracy, consistency, and efficiency.  A language model provides guidance to testing experts in the construction of meaningful test cases that assure provision of needed functionality.

Documentation ¬– Writers of both user’s manuals and on-line help can benefit from organized language that represents the roles, processes, events and resources of interest to the users of information systems.  Context-sensitive help can be driven directly from the terminology that is modeled and understood via business language analysis.  The key advantage is that documenta-tion and help is in the user’s language.