•Intro – application architect and designer, specializing in component-based, object-oriented solutions using modern technologies. •Over twenty years experience in application development. •Prior Sacramento DAMA President and board member.

•Anyone who has attended my discussions in the past or has worked with me, knows that I do not view ‘data’ in isolation, either from an operational standpoint, I.e. static aspect of storage/retrieval, share-ability, or from a functional standpoint, I.e. usage, description, meaning. To me it’s all bound up in context. •The title of this discussion evolved from suspicions that there must be something wrong. •I’ve always felt, and have shared with others, that we’re are still in the alchemical phase of software solution development. •Many of you may have already come to the conclusions that I’ve come to, so please bear with the discussion and share your views as well. •The title of this comes from a pattern of understanding that exposes other truths based on opposites and not just a contrary attitude. •Also, if you’re here thinking that I’m dumping on users then you have mistaken the tongue-in-cheek nature of the spirit of this discussion and what I hope to achieve. •My objective of this discussion is to influence how you think about your work and how you may approach that work in the future. I want to give you some tools to help.

•The Customer is just one example and probably the most visible and ubiquitous one. We’ll be talking about others later. •BTW - Also, later we’ll discuss different entity classification types and their problems. •Every organization for which my responsibility was to understand, analyze, fix, model – whatever, the structures, suffered this problem. •I see it in the data infrastructure of large commercial software. In some cases it’s appropriate for small shrink-wrapped solutions – but it’s inappropriate for large-scale enterprise-wide solutions (which, I understand also suffer from this).

•I’ve been thinking and applying the learnings for many years; hard to articulate. Actually, a friend of mine, Doug McDavid pointed out Alfred Korzybski’s work – we’ll talk more later. •Often these technique are met with resistance since it is not “modeling as usual”. •Example of the WHEEL. Flying – flapping wings (although theyare having success with electronic bees and flies. •Ancient ways of thinking continue for force inelegant, brittle solutions.

•The information we have and use is really a ‘system’ in itself. The ‘knowledge’ we derive from this information is basically the resonance or the emergent property or properties that the system produces. •Each individual, such as an application user or creator of an application, analyst, modeler, designer, etc., understands and approaches each software element, whether it’s an attribute, or the algorithm or definition of the element, with a unique and, often slightly different, intention. •That is, each individual could have different images (non-verbal) of what the various words mean and, in the composite form of a complete application or business function, we each can interpret and execute processes with different intentions and expectations.

•We usually think of these as NOUNS or THINGS in the business. However, these are not really nouns but more like adverbs, that is, they infer a description of an activity – such as event. That is, something happened that caused a Thing do go into a certain state of being. •There are many terms that represent the Role of something rather than the permanent status of something. That is, these types of words describe a situation or relationship that some essential thing is in. •Some valued stock, bond, or contractual agreement may be a Security or an Asset. •A Boat, Car, Savings Account, Intellectual Property may be an Asset. •Any number of things, Contract Clause, Budget Line Item, a cashed check, etc. may be an Issue. •Note – all of these things can share these very same terms within the SAME ORGANIZATION!

•The questions we ask, from different perspectives, e.g. the Marketing perspective, from the manufacturing perspective, from the sales perspective, from the R&D perspective – are very different – yet they’re about the same Party? •Frequently what we see, are ‘Active’ and ‘Inactive’. That is, an ‘Inactive Customer’ which can be viewed by Sales as “No longer a Customer”. But from Marketing, they may still care about the Parties that are no longer a Customer. Yet, there may be difficulty about the definition according to Marketing and may skip the opportunity to Poll an Inactive Customer. •Bottom line – flags indicate there’s something wrong. This is where technology has caused a mutation of semantics. That is, from a performance standpoint, the flag is a quick and dirty way of answering certain questions – however that answer is usually from a very narrow perspective, e.g. Sales. Of course, over time, Marketing may have slipped in their own Flag to deal with whether or not they should Poll the Customer.

•Back to the intention of the company’s requirements and the system’s requirements: •I always see “Maximize Customer Satisfaction and Share value. •I always chuckle at this meat and potatoes answer – since I know that that organization’s processes and support systems are not positioned to meet the mission. •Also, in my experience, there is too little consideration of what the measures are for these statements. An if there are measures, no clear plan for achieving them.

•This is one of those sadistic yet necessary exercise to take an organization through, particularly at a strategic level to develop consensus around priorities of development efforts. •It’s often the first exercise whereby in a requirements planning session the higher-level principals are brought together to level-set. I often start at a flipchart with the word Customer on top and underlined. I say, “Does everybody know what the Customer is?” •Everyone nods yes in an off-handed manner. And then I ask for a definition to write on the flipchart.

Each Function has its specific goals and critical success factors. That is, each function has its specific non-verbal processes and interactions. Therefore, we can say, when each Function operates it uses its own language to communicate internally. Also, it uses another ‘special language’ when it communicates with other sibling Functional units; yet another with external functions.

•Don’t for HR and the employees, maybe Unions, etc. •And what about Maximize Share Value? Does the cost of doing business influence share value? Yes – so the paying customer isn’t the only kind of customer that adds to the bottom line. •That is, in the same Organization, one department may claim a “Customer” is active while another department in that same Organization may claim that same “Customer” is inactive –and they’re both right! •E.g. Joe Shopper canceled his Credit Card but still owes money on the Credit Card

•Often, people know what kind of ‘customer’ they are referring to in a given situation; that is from a unique perspective. •This is where I suspect significant opportunities for change – which also means significant resistance as well. •That is, many requirements analysts (not requirements gatherers) believe it’s important to represent the business throughout the ‘system’. Although I believe that’s correct from a ‘desire’ perspective, I believe we are choosing the WRONG concepts to represent. •SIDEBAR – talk about business VIEW and system VIEW (architecture) •In object modeling, we pretty much have done the same thing by having, for example, a Customer object. •It’s these perspectives on business and how we conduct business that paralyzes our ability to create the WHEEL or solutions.

Language is how humans communicate. We have many languages depending on culture, and with whom we’re trying to communicate within a culture, I.e. a sub-culture. We use languages to communicate with other ‘systems’. Systems, like computer systems, are another type of culture. The language we use for business describes the non-verbal activities humans use to conduct that business. The words and noises we make to conduct business record-able, however, there are other queues in business that are not record-able, like body language and facial movements, like the ‘evil eye’. The ‘easy’ part (which is also the part that requires the biggest shift in thinking) is the language we use between the human and the human interface. In this, we try to mimic as much of the human-to-human interaction as we can remember. ASIDE: I see the users’ (corporate and general public) patience threshold diminishing – the applications are trying to provide the human-to-human experience but they fail horribly because they don’t cover enough contexts and over the phone the applications are horrible. And, worst of all, these applications do not allow for error. We are forcing citizens to think like programmers – who, in the end (no aspersions of programmers) often use incorrect structures and workflows to begin with. The problem is circular.

•That is I can be a father, I can be a son, a husband, teacher, employee, anything depending on the perspective of a particular relationship. That is, I’m a Father to my son, a husband to my wife, an employee to my employer. Throughout all these relationships I am the same Person. •Therefore, there is no such ‘thing’ as an object in and of itself. It always has some type of relationship to something else, so it’s the relationship that gives one or more contexts. •In one application, using common methods, there’d be a Son table, Husband table, an employee table… •But, wait, you’d say for some of these I may have a flag to a ‘relationship type’. Well, that’s because most business domains don’t care about Father / Son relationships. However, that’s not true either. •Insurance, Welfare, and other ‘entitlement’ systems do. In these systems we’d see (draw this) •How does business measure the RELATIONSHIP and what do they measure?? Let’s get to that now…

•For example, I purchase gas using my account. That account knows every time I’ve made a purchase. It can tell me the last time I made a purchase and how much I paid. That account can even tell me how much I’ve spent between October 24, 2000 and January 6, 2001. •Depending on my criteria as a business, that Account can tell me whether I’m a good Customer, if the business defines a “good Customer” as one who buys more than $200.00 per month and makes the payment on time. Of course, altering the criteria can easily change that policy.

The role provides the context for the Account. That is, it give the Account, and by extension, the Party, the reason for its participation in the system. The role establishes the type of activities the Party via the Account, can perform. Most importantly, it give contexts to other roles, that is, a Purchasing Agent may care about a Vendor; a Research and Developer may care about a Customer (end purchaser) who Return a Product.

Here we show the the Role has Authorizations. The Authorization is an ‘Command’, I.e. program execution request.

Generally, an Entity could ‘play’ many Roles. An Entity playing a Role is often in one State. Of course, this is arguable where we can say something is in many ‘states’. However, a state is often ‘viewed’ from a particular context. That is, from one stakeholder context, it’s in one state. Also, states can be derived. E.g. an Order cannot be Returned without having been Sold.

Typically, in my experience I always see Order tables with various ‘state’ flags and dates. In this view, the states are clearly enumerated. In object based models, the specific features of the states are enumerated in each state. E.g. Date, Reason, etc. The only thing ‘interesting’ about Order may be its unique ID. Different Functions tend to call the same State different Names. Or even confuse names, like calling Canceled – Rejected. Or they’ll overload terms by calling Canceled – Stopped. What about internationalization and cultural problems. Some cultures may have problems with certain words that evoke certain images. Traditionally we’ve spent lifetimes of productivity arguing over names. The difficulty is coming up with models and techniques that minimize the issue.

As stated earlier, most of our soft-problems are due to our inability to express terms appropriately in relationship to the context, which is a n-wise relationship. Often language is the source of difficulty and not the solution. I love the new voice questionnaires that ask for, for example, your zip code, and then say, “OK, your zip code is nnnnn.” The applications deal in DATA only. It’s not really information. However, the applications ‘tell’ you things directly. This can be good or bad information, which one can easily repudiate. The exformation is the information that is not ‘told’, however, it’s clear that it’s true. For example, if the data states: no rain, no wind, then the exformation is ‘It’ll be a nice day.” Culture: Our business cultures both internal to the organization and external usually are different to varying degrees. There is also problems across ethnic and national cultures as well. Often, these systems are designed by individuals who do not participate in the business culture or even the community’s culture (sovereign or ethnic).