Thoughts on business requirements, models and rules

Moving to a new site

2009-04-07T00:57:00Z

I have started a new blog at http://organizingknowledge.blogspot.com. I will be continuing to post my observations there!

Thank you for reading this blog and I hope to hear from you at my new site!

Andrea

Continuing "What makes for a "good" model?"

2008-12-17T06:18:00Z

In my last post (I was told that some people's heads exploded when reading it :-) ), I talked about some fundamental modeling concepts and how they help to define classes and their inheritance. The 3 concepts (defined by Guarino and Welty's work on OntoClean) are:

Essence - these are concepts (Guarino and Welty call them "properties") that are true for all instances of a class and that "define" the semantics of the class, such as the "property" of "being human"
Identity - concepts/properties that determine the equality of instances
Unity - concepts/properties that define where the boundary of an instance is, or distinguish the parts of a "whole"

Essential properties are known as "rigid" properties. But there are lots of non-rigid aspects of a class like its purpose, current state or some quality, such as its color(s). These non-rigid aspects are categorized into 3 types:

Phased sortals - These are properties whose values change over the lifetime of an instance. This is exemplified by the properties "being a caterpillar" or "being a butterfly" for the class, Lepidopteran. The same individual lepidopteran starts out as a caterpillar and later becomes a butterfly. There is only one basic class with identity - that of Lepidopteran.

Another interesting example is the concept of "county". County actually carries two meanings - that of a geographical area (which does not change identity or value) and that of a geopolitical area (which can change in size, name value, or even cease to exist). Care should be taken to make sure that the invariant aspect is modeled as a class.

Roles - These are properties that define how something participates in an event, activity or state of affairs. For example, a dog might be a pet, a pest or food - depending on the type of dog and area of the world. So, having a "pet" or "food" supertype for a dog would be quite invalid. This is really a description of the dog's purpose, not its subsumption.

Another example is the concept of an "agent" - perhaps a human, a social club, software, a legal entity, etc. Yes, any of these entities could act as an agent - at any point in time - but this is not an essential aspect of their being. It would indeed seem odd to make "agent" a supertype of any or all of these entities - yet, I have seen it done in models.

Attribution - These are qualities of an instance, such as separating red and green apples, or MacIntosh versus Gala apples. Attributes serve to create ad-hoc groupings - and the need for various groupings and therefore various attributes evolves over time. A grouping that might seem important today will very likely lessen in value over time.

As is probably obvious from this discussion, non-rigid properties/concepts should never occur in the backbone of an inheritance hierarchy! The backbone should only contain the invariant aspects of the domain being modeled. Similarly, these properties would never be identity or unity properties! These should only be properties within a class or related to a class/instance.

I thought that these distinctions were pretty fascinating - and that without consciously thinking about them, we can and do create erroneous models.

Anyway, I'm now done with my overview of Guarino and Welty's work. And, my apologies if anyone's heads exploded a second time. :-)

Happy Holidays!

Andrea

What makes for a "good" model/ontology?

2008-11-17T23:59:00Z

Recently, I have been reading about models/ontologies - their development, formal analysis, mapping/merging, and similar concepts. Being geeky, I was drawn to the book, "The Handbook of Ontologies" (ISBN 3-540-40834-7, published by Springer-Verlag in 2004). In it, I found a chapter on the philosophy behind OntoClean (Chapter 8, "An Overview of OntoClean"), which was written by the originators of the methodology, Nicola Guarino and Christopher Welty.

What Guarino and Welty did was analyze what it means to create a "good" ontology - in other words, they defined the heuristics behind a "good" model. They did this by starting from philosophical first principles - understanding that the basics of a good model was something that philosophers themselves had "been trying to describe ... in a formal, logical way since the time of Aristotle." They talk about philosophers struggling "with deep problems of existence, such as God, life and death, or whether a statue and the marble from which it is make are the same entity." (Now, I must admit that I have never had a "God" class in my models, but the discussion did remind me of arguments about whether a computer and its backing hardware the same thing? I always said "no" but now I have philosophical and computer science reasoning to back me up.) :-)

Anyway, back to Guarino and Welty's work... They focus on 3 main ideas - essence/rigidity, identity and unity. I will try to explain each below and give examples. BTW, I have to first give a brief explanation of the word, property, since the semantics vary a lot in the literature. In this work, a property is the meaning or intention of an expression (so a property is T or F, a unary predicate - for example, "being a human" or "having a brain"). Now, back to essence, identity and unity:

Essence/Rigidity - A property that is essential is one that must be true for all instances, at all times. This means that the property is "rigid". Here are a few examples: An Apple (the property of "being an apple") is rigid but a RedApple is not rigid - aka anti-rigid. "Being red" does not affect whether a thing is an apple. This implies that "RedApple" really shouldn't be in your hierarchy as a backbone concept, but color could be an attribute on an Apple - if you needed to distinguish red from green, for example. On the other hand, "being a person" is rigid but "being a student" is semi-rigid (meaning that the property can "acquire or lose (some of) their instances depending on the state of affairs at hand").
Identity - Is a property by which one can determine the equality of instances and by which one can reason over equality (i.e., entail equality). This requires an ability to recognize instances as they evolve over time and at any point in time. A great example is that the property Lepidopteran (an order of insects that includes moths and butterflies) carries identity, but the properties of caterpillar and butterfly do not. If you went straight from modeling "LivingBeing" to modeling a caterpillar and a butterfly, you would be missing something important - how to identify the individual. A single instance of a lepidopteran may be a caterpillar or a butterfly at different points in time - but it is still the same instance. So, "being a lepidopteran" is the thing that "owns" defining identity - and this is inherited to a caterpillar and a butterfly.
Unity - Is a property by which one can distinguish a whole from its parts, and/or distinguish the boundaries of an entity. It is defined by a "unifying relation" - such as a topological relation (based on continuity of space, such as a lump of coal), a morphological relation (based on form or structure, such as a constellation) or a functional relation (based on function/use, such as a bikini). The bikini is a great example, because it indicates that a whole may be made up of other "wholes". Let's look at a few more examples: A Country (as a geopolitical area) has identity and unity (but may cease to exist), but something that does not have unity is a GeographicalArea. The latter does not have a single "unifying relation" which defines it. Its boundaries can be determined differently, based on different perspectives. But a GeographicalArea does have an identity - we can give it a name or location. On the other land, Water or Clay are anti-unities. They are just descriptions of an amount of something, not "whole"s in and of themselves.

Building on these basic concepts, Guarino and Welty define criteria for analyzing an ontology. Here are several rules and some examples of the rules in action:

If a property is anti-rigid or anti-unity, then any properties that it subsumes (that inherit from it) must also be anti-rigid or anti-unity. For example, it would not make sense to subclass a Person from AmountOfMatter - since a Person is a whole (a unity) and Matter is an anti-unity (it can be divided into different instances/groupings). Certainly, a Person is composed of Matter, but a compositional relation is not inheritance.
If a property carries identity or unity criterion, then any properties that it subsumes (that inherit from it) must also carry that criterion. For example, it is incorrect to subclass a SocialEntity from a GroupOfPeople - since a SocialEntity is more than just a GroupOfPeople. You might have two SocialEntities (a neighborhood watch team and a beautification organization) that have the same members (are therefore the same GroupOfPeople) but they are very different Entities. Also, if the membership of one of the SocialEntities changes, the Entity itself persists, but the GroupOfPeople changes. (Wow, these really aren't the same but I have been guilty of making this mistake. Now I know why it was so hard to maintain the identity property for a Group or Collection - and why I always ended up using a string Name!)

There is lots more to write about analyzing non-rigid properties. But, I will get into that in my next post.

Andrea

Question on what "policy based business" means ...

2008-09-10T22:53:00Z

Someone sent me a private email asking about the origins of the name of my blog. So, here it is ...

I originally started working on rules and expert systems a long time ago in a galaxy far, far away - in fact, it was Intel Architecture Labs, under a very smart leader named Hans Witt (Hans is now part of Haley). I went through lots of different directions over the following years, including time at Cisco working on networking SLAs, firewall and configuration rules, etc. And, I spent time in the DMTF and IETF authoring policy models and RFCs (take a look at RFCs 3060, 3198 and 3670). But, in spite of all the low-level, siloed work, I kept believing that policies and rules were motivated by the business and its needs (and not specific technologies). And, I kept believing that we were missing the most important user/customer of policy - the business. I ended up at Microsoft focusing on business - working to capture a business' goals and ways of doing business (corporate policies, management directives, processes, vocabularies) as formal, analyzable definitions that could then be acted upon by existing infrastructures. The goal of the work is to go from a business' "natural language" to artifacts that can be refined in model-driven infrastructures.

There are certainly lots of tools and standards in the business process, business modeling space - but only for the educated professional. :-) For example, there are business process diagrams that can be expressed in BPMN (Business Process Modeling Notation), collaboration, activity and use case diagrams captured in UML (Unified Modeling Language), tool-specific definitions of "interactions" or "communications" (usually saved in some proprietary XML), data models focused at a conceptual, implementation-independent level (perhaps captured as UML objects) or a specific database's definitions rendered as entity-relationship diagrams, and on and on. Then, you can capture rules as UML's OCL (Object Constraint Language). Or, you have the "business rules" approaches. There are many of these tools around - but they are again geared to the educated professional (dare I say, programmer?) and usually targeted at a single, backing rules engine.

None of this is really accessible to or usable by a business person. I was told by several of my customers that business people use three tools - documents and emails (written word with some pictures and graphics) and spreadsheets. Period, end of story. So, none of the complex diagrams or acronyms really help in this space. But, there are some options that go in the right direction. Ron Ross advocates writing rules in a clear, precise manner - "RuleSpeak" (http://www.brsolutions.com/p_rulespeak.php). If we have this, should we be able to formally analyze the vocabularies and rules, and then transform them to UML and many other encodings? Yes! And, could we share this data and interoperate based on standards such as SBVR, the Semantics of Business Vocabulary and Business Rules from OMG (http://www.omg.org/spec/SBVR/1.0/)? Yes! Cool, "policy-based business".

From another angle, Forrester wrote an interesting piece in May 2008, under the title, "How the Convergence of Business Rules, BPM and BI Will Drive Business Optimization". That report has a great graphic that business policies drive processes and rules, which in turn consume and generate data. Forrester says "Enterprises are run by policies". I take that as validation of the "policy-based business". :-)

Andrea

Human Interactions and Business Processes - OR - "Processes Don't Do Work, People Do"

2008-09-10T00:28:00Z

The quote above comes from The People Are the Company by John Seely Brown and Estee Solomon Gray. It is a great quote highlighting where business process tooling seems to fail - in handling human interactions and their approaches to processes and problem solving.

This is the subject of a book (written in 2005) by Keith Harrison-Broninski, Human Interactions, The Heart and Soul of Business Process Management. The information is also overviewed in a paper by Harrison-Broninski at http://human-interaction-management.info/A%20Role-Based%20Approach%20To%20Business%20Process%20Management.doc. The paper and book describes the mismatch between human-driven and machine-driven processes, and that most processes are the former, while most tooling supports the latter.

The mismatch with human processes is that:

People evolve and adapt a process depending on various factors (such as what they learned in another process or iteration)

Therefore the process canNOT be prescriptive but should be "supportive"

People work multiple roles and/or processes simultaneously and may bring knowledge from one role or process into another

Who a person is, what they do and what they know make a difference to the outcome

People turn information into knowledge and incorporate that knowledge into the outcome

Information and knowledge are not static

People jump around in a process trying to be as efficient and effective as possible

Again, the process canNOT be prescriptive but should define a typical/best practice approach

So, where do we go with this? The author suggests using and modifying Role Activity Diagrams (RADs). Before reading this book, I had only a passing acquaintance with these diagrams (since there is almost no tool support for them). RAD was conceived quite some time ago - it was proposed in 1983 by Holt, Ramsey and Grimes in Electrical Communication. Although not widely implemented, the concepts are quite valuable and should be used to inform BPMN and other high-level process modeling work.

OK, then, what are the main concepts in RADs? These are defined as:

Roles (divisions of responsibilities)
Users (specific humans, organizations/groups, machines, etc. assigned to/placed in roles)
Resources (any process object and/or information)
Activities (one or more tasks that manipulate resources)
Interactions between roles
States of a process (logical conditions that control execution and validation of activities)

You can probably see the corrollaries and differences vis-a-vis BPMN (Business Process Modeling Notation, http://www.bpmn.org).

And, what modifications are needed? These are discussed in Chapter 3 (a "New Theory of Roles") of the Human Interactions book as:

Adding attributes to roles and users (more on this below)
Use of a role to start, stop or manage processes - which means that anything can be a resource/trigger and can be shared with another role or user
Ability to track that multiple copies of information exist as a normal part of the process
Allowing jumps from one activity to another, along with repeating and interleaving activities as necessary

This directly relates to the fact that a process is informational, and not prescriptive, and that each activity should have pre/post-conditions to define when it can occur

Activities are not atomic (just as BPMN processes are not atomic) but can be further defined/refined
Interactions are not synchronous - there are multiple channels for sending and receiving resources/information

These thoughts really resonated with my experiences, and suggested areas to work to better capture business process information.

I did want to expand on what Role and User attributes were deemed valuable (I mentioned this in the list directly above). For Roles, these are:

Goals (terminating conditions)
Responsibilities and requirements ("always true" conditions)
Necessary data/information
References to other roles (to get more information)
Capabilities
Process authority

And for Users, these are:

Identity
Physical and virtual location
Private information (beyond what is provided in the Role)
Relationships (at the instance level)
Behavioral tendencies
Capabilities
Organizational authority

Pretty interesting! More on this in later posts.

Andrea

Interesting book chapter on defining a model ...

2008-08-17T09:27:00Z

But, it is really a chapter of a book on implementing ITIL (IT's Infrastructure Library) Configuration Management!

http://www.informit.com/articles/article.aspx?p=1154763

This particular chapter is about figuring out what types of "configuration items" (i.e., IT objects) need to be managed, what instances of those objects need to be populated, and how the properties/attributes of the objects are determined. These topics are described as "scope", "span" and "granularity".

Under scope, the article highlights the importance of understanding both things (software programs, computers, etc.) and relationships. For me, relationships are as important as the objects themselves (maybe more important!) - since they describe dependencies and coordinations between objects that become the critical details behind analyses (think about root-cause analyses!).

Although the subject of what is modeled may vary (IT items versus online shopping accounts), the discussion is quite good regarding thinking about modeling alternatives ("do I need to model everything?"), and makes some concrete suggestions on how to proceed. For example, book chapter lists the following "criteria ... to determine scope" (determining the concepts that need to be modeled):

Start simple - start with the things that "can be quickly learned and easily maintained"
Consider the cost - "what [can you] afford to manage and what [can you] afford to ignore"?
Score easy victories - "build confidence early"
Look ahead to value - "look forward to projects your organization is likely to tackle ..., and structure your ... [data] to provide the information that will be needed"
Reduce your risk (related to the data) - determine how you will gather the data and "how you will manage that data"

The other interesting thing about the book chapter (at least for me) is that it highlights the value of CIM, the Common Information Model from the DMTF (http://www.dmtf.org). As ex-VP of Technology of the DMTF, that is very cool!

Andrea

Musings on policies and rules of different types, dealing with different scopes

2008-08-06T03:36:00Z

There are many different kinds of policies and rules - going from high-level corporate policies on how business is conducted and its information is secured, to extremely low-level rules about how a specific component in a piece of hardware or software operates (for example, garbage collection in the OS must be run at least once every 1min). Are all of them defined and managed the same way? I don’t believe so, since the scope of the policies/rules and the definitional environments are very different. (By the latter, I mean that the policy definers speak different “languages” and use different tooling. For example, business people "program" in tools like Word, Excel and Outlook. :-)

Now, traditional programmers will raise cries of disbelief that business people program in Word. However, consider a well-written business requirement document - this defines a business process, its data and flow, requirements for validity checking, algorithms for calculations, decision points, etc. Sounds like a program to me - but we don't capture it as such. We think of it as unstructured data which has missing information (usually basic assumptions and definitions that the business person thinks too obvious to write down, but that a programmer unfamiliar with the environment misses completely) and errors (unstructured data can't be analyzed). But, what if we could analyze Word docs? (I will come back to this in later posts.)

Let's go back to talking about types of policies and rules - and interactions between different types and scopes. Even though policies and rules might be defined in specific, isolated "communities", they do impact each other. One example is where government-mandated compliance policies may override business processes and rules. But, this is pretty easy to understand since they are both defined at the "business" level. Another example where intersection of rules might occur is where an IT policy causes a business application to fail or perform badly. However, since these are defined by different people in different scopes - you usually don't know about a problem until it happens (too late). It would be good to know where these overlaps and problems are, before they happen. Doh!

So, simulation is vey important - but I think that more is needed.

Analysis of business definitions and requirements - maybe using existing ontological map/merge techniques (!) - would help to find errors and inconsistencies at the same policy level. (That takes us back to the importance of analyzing Word docs.) And, the ability to tie rules across levels using KPIs (key performance indicators) and SLOs (service level objectives) is one way to go. Implementation-specific or monolithic rule structures seem like very bad ideas to me. Also, a universal policy language (usually based on if-then-else programming constructs) seems wrong to me. The latter is too deterministic ("a gold customer must get at least a 10% discount on all purchases" is not as deterministic as it appears :-), and it would be crazy to tie policies from high-level to low-level in a single definition.

Andrea

What are business policies and business rules?

2008-07-30T06:10:00Z

Forrester says that "enterprises run by policies" (in their report from May of this year, "How the Convergence of Business Rules, BPM and BI Will Drive Business Optimization"). In turn, "policies create processes and rules", which "consume" and "generate" (and validate) data. (I like it!)

But, what is policy? And, if we know what policies are ... what are rules?

Stanford’s Policy Repository (http://www2.slac.stanford.edu/policy/definitions.asp) defines policy as “A statement of principles and/or values that mandate or constrain the performance of activities used in achieving institutional goals. A policy is general in nature, has broad application and helps to ensure compliance with: applicable laws and regulations; contract requirements; and delegation of authority by the University Board of Trustees. Policies promote operational efficiencies and reduce institutional risk. Policies do not contain requirements. Directives, processes, procedures, work instructions, and the like flow from policies and the requirements are specified in them.“

Well, I don’t think that we can formally define and implement these kinds of policies, but we can capture them (and the instruments where they are defined, such as documents), and then capture the details and artifacts (procedures, rules, work flows, etc.) which “flow from" them. (Traceability and refinement are very important here, and I will be blogging more about this in coming months.)

As a counterpoint to the Stanford definition, we have the famous/infamous Wikipedia. http://en.wikipedia.org/wiki/Policy defines policy as “a deliberate plan of action to guide decisions and achieve rational outcome(s)”. Wow! This is very different, and sounds more like a process (whenever people start to talk about "plans of action", I think process and workflow).

I would like to take the position that policy is indeed guiding principles and values - but that we can only analyze and encode more concrete forms of these, i.e. the processes and rules that flow from them. This then highlights the importance of capturing both the processes and rules - in conjunction, not in isolation/separate silos. Too many tools/diagrams/models and businesses focus on only one of these aspects at a time!

So, what are processes? Collections of connected activities, events, decision points and data input/output. Yes, we can make this more complex - but I think that these are the basic concepts.

And, what are rules? Specific invariants, constraints, directives, validation checks, etc. for the processes and the data. I could even go further to say that rules are only those things that are encoded in software - but I am not willing to take that step. (Software isn't everything :-) - there are a lot of human processes and human rules.)

Andrea

Names of the entities in a model - What a rathole!

2008-06-06T00:28:00Z

While writing my last post on iterative design, I touched on naming entities in the model. I want to take just a few minutes to highlight some guidelines that I use for naming ...

Do make the discussion about name choices a significant part of the model review process.
Do not be afraid to use verbose names.
Do involve user education and documentation experts early in the design process.
Do search the web for other names and other meanings for the name that you select - just to educate yourself on alternatives and alternative interpretations.
Do reserve the best names for the common scenarios. (For example, as noted in the last post, don’t use the name "computer" to refer to a hardware chassis for a computer.)
Do ensure consistency in naming.
Do assume that at least one person will be vehemently opposed to an entity or attribute name. Make the best naming choice possible, clearly explain the entity’s or attribute’s semantics and explain the name choice, and then move on.
After following the above guideline, consider changing an entity or attribute name only when it is erroneous.

Hope that these help!

Andrea

Iterative design and combining the knowledge of multiple experts to create a "good" model

2008-06-06T00:25:00Z

Sorry to be missing-in-action again. But, my daughter's end of the school year, vacations and work seem to have gotten in the way of blogging. Well, I'm back ... :-)

The topic of this post deals with creating a "good" model - and the need to combine domain AND modeling expertise to accomplish this. Individuals with either kind of expertise, working on their own, will not define a "good" model - since each lacks the experience and knowledge of the other. In addition, a "good" model typically requires multiple iterations. The first pass design should be considered solely as a prototype for evaluation and refinement. At least one more design pass is usually required to obtain even a reasonable model.

In the book, Framework Process Patterns, Lessons Learned Developing Application Frameworks (Addison-Wesley, 2002, ISBN 0-201-73132-0), Carey and Carlson discuss this development approach as the pattern, “Where’s Mr. Spock When You Need Him?” or “Domain-Technical Cross-Team Communication.” They say: “[D]evelopers need in-depth information about the domain functions for which they have responsibility. The earlier this information can be transferred, the less likely that … errors will be introduced, and those errors that are introduced will be less costly to correct."

Another valuable guideline from the book is to consider areas where the domain experts disagree or where their answers are “it depends” to be areas for possible extension and customization. Carey and Carlson discuss this under the heading ... "It Depends" (aka "Identifying Customization"). The intent of the pattern is: “To find potential extension points (points of flexibility …) that have been missed, … [ask] leading questions and …[listen] to domain experts discussions and arguments. “ In the pattern solution, Carey and Carlson recommend that you “listen for key phrases (for example, ’It depends’) that indicate the need for customization. Listen for domain experts arguing. Often the points of contention are extension points.”

I have used both of these approaches and can testify to their value! It is great that Carey and Carlson documented them so succinctly!

Now, after having extoled the wonders of cross-group (cross-model and domain) collaboration, I have to point out some downsides ... the terminology that both groups use is usually quite specific. It is always a good idea to consider the terminology of the individual domains but also to generalize and abstract it for reuse and extension. In order to correctly capture abstractions and concepts, it is usually necessary to get past the specific terminology and constraints of a single domain.

A case in point is the use of the term, “computer”. In some contexts, it is a specific entity that that has a processor, disk, memory, etc., whose piece parts are contained within a physical chassis. In other contexts, it is solely virtual (just a logical entity providing “compute” capabilities), such as a virtual machine or a “grid computer”. If your model reflects a “computer” as strictly a physical entity, then another term must be found for the virtual system. In addition, one must deterministically know when an entity is the computer or the virtual system. Unfortunately, this answer usually depends on your perspective. The answer could be different when examining the system from the perspective of the operating system (with internal knowledge) versus as a user.

Then, there is the secondary problem of terms with multiple or ambiguous meanings ... Unless you have a very flexible tool, users of the models will quickly tire of trying different queries, against different type hierarchies, searching for their concept of interest. Always consider this in defining entity names!

I need to come back to the iterative aspects of defining a model, for a bit ... and caution against the “big bang” approach to modeling – where everything goes into a model at once. Iterative design suggests that you start with “what you know” – such as using operational observations to drive the general abstractions and specific subtypes of a model design. This design can then be refined and tested. The results of each iteration influence the follow-on work. For example, one could indicate the desire to include organizational data in a design by creating a basic namespace and generic abstractions. In some work that I did, this was accomplished by defining an "Organization" namespace, and an abstract OrganizationalEntity (clearly indicating that the type is still in development by the use of meta-data, isExperimental=”true”). Then, in a later iteration of the model, sub-elements and sub-types were added to give substance to the type.

As part of the iterative process, it is very valuable to review a model outside the team that defined it (it is especially valuable to talk with customers), learn from mistakes and then update the model design. This should be done at least once, but ideally until the only feedback is that "this is an excellent model". :-) When doing reviews, put focus on the top of the model hierarchy - since that is where extensions will occur and where key conceps are captured. However, the leaf entities are certainly not exempt from review and refinement. In addition, always try to use/query the model as part of the reviews, and try to extend it. This really helps to highlight errors, ambiguities and missing semantics.

Andrea

Observations on how business and IT people differ in how they think

2008-06-05T23:37:00Z

I attended a talk yesterday, given by Roger Martin (Dean and professor of strategic management at the Rotman School of Management). He argued that businesses are driven by "analytical thinking" - the need to refine, examine and measure the past, limit bias and minimize judgment in any conclusions. The goal of all this is to have reliability (consistent, repeatable outcomes). Yet, to stay competitive, a company also needs innovation. And, this is really what software/IT development is about - new code and new ideas, and not just improvements and refinements in algorithms and process. This second kind of thinking is "design thinking".

Design thinking is about finding new heuristics and algorithms, not about refining existing ones. In this world, one considers the future - along with some bias and judgment calls. The goal of this is to have validity - the production of future outcomes that meet objectives. Wow, these two worlds are really different - and I have seen the differences come out in many discussions, in many ways.

For example, I am working with some IT customers on new ways to capture and formalize business information. But, the business people are very reluctant to work on this - not wanting to give up any information or to change anything. In fact, in the business world, most new strategies are looked on with skepticism. (This may be why companies like Cisco get the majority of their new ideas from acquisition instead of internal innovation. I used to work there, so I am speaking from some experience.)

According to Dr. Martin, all these problems stem from the differences in analytical and design thinking. He told a story of consulting to a bank and recommending a new operational strategy. The head of the bank asked if the idea had ever been tried before. Energetically, Dr. Martin said "NO!" - and that was the end of the idea. For a design-thinker, "NO!" was a great answer - a chance to leapfrog competition and define whole new heuristics and algorithms. For an analytical-thinker, it was a departure from the past with no sense of reliability.

So, what did Dr. Martin suggest? He suggested that design-thinkers consider the following when pitching new ideas to business people:

Make "design unfriendliness" part of the challenge in doing the new work
Empathize with the analytical thinkers (who talk about best practices, consistency and proofs)
Use analogies and stories to tie the ideas to past events (In his banking example, he said that a much better answer was that the new strategy was actually based on Swiss banking practices, but adapted to the environment in which he was working. He should have explained why the strategy was based on the past - past Swiss experience and past banking environmental knowledge.)
"Bite off as little a piece of the problem as possible" to generate proof - for example, running a small set of customers using the new strategy for 3 months and examining results. In this way, you get "proof" and have the "past" to analyze.

Similarly, Dr. Martin suggested that analytical thinkers consider "reliability unfriendliness" as part of their management challenge, empathize with the design thinkers and speak their language, share data and reasonings and not conclusions about what won't work, and "bite off as big a piece of the problem as possible" to give innovation a chance.

I thought that the talk was fascinating and plan to implement these ideas in how I pitch my innovations.

Andrea

Warning, Will Robinson - Common, general model designs rarely (never) make for a good physical storage scheme

2008-05-27T19:10:00Z

Here is a guideline that I once wrote and that is often ignored (at least I have no fallacies about my ability to influence people :-)) ...

Do not combine data definitions together into a single instantiable entity when an analysis of the managed environment indicates that they can or should be defined as separate entities. Do not do this even if current scenarios indicate that it is permissible, since a future release will invalidate this decision, your model design and its instances.

The preceding guidelines are clearly about defining a general and extensible model, and not about how it is stored or used. In those spaces, the programmer needs to do whatever is necessary. But, don't confuse implementation and performance issues with general model design. Combining model entities together in an implementation given usage patterns against a store, or separating an entity apart into 2 database tables to prevent sparse tables, are reasonable design choices. But, taking an optimized, physical storage design as a general and reusable model definition is rarely workable (actually, I want to say "never" but I was told to "never say never").

Each usage of a model likely has its own queries, implementation and storage requirements, and necessary data - and hence will dictate different storage patterns. A “common” model is designed to carry and interchange data for many scenarios, and across several products and stores. It is unlikely to be useful (e.g., optimized) as a physical storage definition, for any of the scenarios or stores.

This thinking is what motivated the distinction between logical and physical model definitions. However, usually and unfortunately, people get consumed with the physical store and forget about conceptualization and abstractions. Don't do this!

Andrea

Modeling prejudices - Being unduly influenced by perceptions of compositions/decompositions and physical boundaries

2008-05-27T18:14:00Z

In my previous post on designing a model, I discussed the need to view a problem space broadly and via specific scenarios. Since a model is supposed to serve as a conceptualization and abstraction of a problem space, we have to be careful not to be too broad, too narrow, or to prejudice our design by bringing preconceived notions to the solution. Our perceptions affect all our thoughts and conclusions, especially when we think about the physical.

What do I mean? One example is our mental image of a computer. What usually comes to mind is a laptop, desktop or server system with monitor, keyboard, storage, etc. This is a very physical embodiment of a computer - and certainly somewhere there has to be some physical compute capabilities. But, our model perhaps should support a swarm of microbots (as in the Michael Creighton story, "Prey") as a computer, or allow a virtualized system hosted on a compute-grid to be instantiated as a computer.

Going back to the book, "General Systems Thinking", Gerald Weinberg addresses this issue. “One of the most deeply buried metaphors of science is the concept of a ’thing’ or ’part’ that can be separated cleanly from other things or parts. The metaphor is so deep that we seldom know when we are using it. … These ’things’ or ’parts’ are the possessors of ’properties’ or ’qualities’ that they carry around with them as a box carries matches or a hog carries fat. These properties can be isolated from other properties by isolating the ’thing’ from other ’things’. … Our use of the ’part’ or ’thing’ metaphor is closely allied to our experience of physical space, and particularly to our experience of ’boundaries’.”

Weinberg’s text is quite interesting and I want to analyze it a bit deeper (especially since a box holding matches is a very different thing than a hog’s fat :-)). Matches can be removed from a match box, without affecting the box. A match can be put into another box, without affecting the match. Clearly the box does not consist of what it holds – it is simply a container. On the other hand, fat can’t be removed from a hog without affecting the animal, nor can it be moved to another animal. In this case, the containment relationship is quite a big stronger (actually, it is a composition relationship). So what do we do with the fat? Depending on the problem space, all that we may need to know is the amount of fat on the hog (a property), versus the fat as an individual entity (a relationship). Or, maybe at different times, we need the ability to have both - where the amount of fat is derived from the individual "fat" entities composed into the hog. Wow, you probably never thought that hogs could be so complex. :-)

And, if something is related, can the data simply be embedded within the containing entity? Possibly, but be careful. Entities are typically embedded within other entities for expediency reasons (ease of access or storage) or because something is perceived as only a “part” of something else and never analyzed on its own. Take care that these reasons are not used to “overly simplify” a more flexible model design. Unfortunately, expediency reasons are usually not valid for more than one or two releases, and composition/decomposition analysis may lead to false conclusions.

Again, Gerald Weinberg pulls these ideas apart in his book. He says: “An example of a composition error is this: I stand on a bridge and spit in the river. Seeing that it makes no noticeable difference in the purity of the water, I go to the polls and vote against the municipal bonds for a new water-treatment plant. An example of a decompositional error, on the other hand, would be this: I stand on the bridge and notice that the river is clean, so I conclude that nobody spits in it. To warn us from these two errors, we have two laws. The Composition Law, which goes back at least to Aristotle, says: The whole is more than the sum of its parts. The Decomposition Law, on the other hand, says: The part is more than a fraction of the whole. … Why should we want to remember these? … we shall not find them very helpful at making exact predictions. … But, … general systems laws can help us avoid the grand fallacy on the way to an exact prediction.”

Well, enough deep thinking and philosophy for today! Back to work.

Andrea

Modeling based on scenarios and our prejudices

2008-05-11T23:39:00Z

Back to writing about modeling guidelines .... sorry about the long delay in my posts, but I got caught up in some standardization work that you will be hearing about in the next few weeks :-). I want to talk in this post about scenario-based modeling and how we bring our preconceived notions of the world into our models.

The decision on how to model something (an individual object or a full domain) is heavily influenced by the scenarios that drive the design, and how we approach and understand the problem space. My strong advice is to fully consider both the scenarios and our own prejudices. If you focus too much on product scenarios, you typically miss the “big picture” since product teams only have a limited set of scenarios in scope. But, if you focus too little on the scenarios, you may create a great model that is not useful to the product teams. And, if you read all the scenarios, with a filter based on what you think that the model should be, then you only see this one answer.

In his book on "General Systems Thinking", Gerald Weinberg discusses the multiple views of a problem space:

"Get a ‘complete’ view – one broad enough to encompass all phenomena of interest – so we are not surprised;
Get a ‘minimal’ view – one that lumps together states that are unnecessarily discriminated – so we do not overtax our observational powers;
Get an ‘independent’ view – one that decomposes observed states into non-interacting qualities – so as to reduce the mental effort required.”

An examination of all of these views of the modeled environment is needed in order to determine the states, qualities and entities of interest. This is much more than analyzing scenarios, but deals with understanding and abstracting the “things” in the environment to create the correct entity definitions. And, it highlights defining the entities only after you have done this analysis.

I have been criticized that this approach is "boiling the ocean", looking for big solutions when little ones are needed. I totally agree that it is a bad idea to model beyond current knowledge. But ... it is defnitely a good idea to examine the problem space broadly, and anticipate extension and the support of less restrictive scenarios (which will certainly happen at a later time).

There are some interesting examples of how extensibility and future changes can influence a design. For example, most of us view software as executing on a computer. In fact, it is tempting to tie software to the computer so tightly that they are inseparable (actually embedding the software’s data as sub-elements of the computer’s definition). But, there is an interesting world of agent-based software that makes those assumptions problematic. Agents execute at different times in multiple locations, carrying along their state and data as they move within a network. Although physically it is true that the agent stops executing on one computer and then is “reborn” on another, logically that is incorrect – since the “same” agent is reborn. Modeling for the standard scenario of strict deployment on a single computer makes the agent-based scenario cumbersome. However, anticipating less restrictive scenarios enables evolution of the model versus its rejection as cumbersome or incorrect.

So, it is a good idea to think broadly about the entities to be modeled, and then to make reasoned choices in your design (versus making uninformed choices). Larry Page, in an interview in Fortune (May 12, 2008), said "If you look at the people who have high impact, they have pretty general knowledge. They don't have a really narrowly focused education." Now, I admit, he was talking about innovations that change the world - but model that are supposed to support a changing environment need these same principles of being based on general knowledge and broad thinking.

Well, I will end on this very philosophical statement :-). More on this in the next installment.

Andrea

Great WSJ article on business and IT

2008-04-07T02:08:00Z

I'm not sure if folks took note of the Wall Street Journal article, "How to Tap IT's Hidden Potential" from March 10th. Interestingly, I just had a conversation with some IT customers on the question "Is IT a core business of my company?" Opinion was split between yes and no - "yes" because a company cannot function in the current environment without IT and it is a source of innovation and improvement for the company, and "no" because without the business itself there would be no need for IT (IT is just a supporting organization in the enterprise).

The WSJ article argues these same points and concludes "that CEOs can't ignore IT and expect to succeed. Technology has accelerated the pace of change in business, making it crucial for companies to detect, assess and respond to every opportunity and every threat as quickly and as effectively as possible. And that kind of agility can only be achieved by fully embracing the operational and strategic importance of IT." The article goes on to give several steps for bringing IT and business closer together. Briefly, they are that:

The business' CEO and executive board understand IT as well as they understand "accounting, finance and marketing"
The CIO not just be technically focused but understand how IT and the various aspects of the company's business can be integrated (and then actively works at this)
Executives rotate through IT, and IT personnel integrate with the business units
All managers understand the values that IT brings to the business ("knowledge management, business intelligence, information security, change management and process integration")
People be able to translate IT and business concepts - so that "nothing gets lost in the translation"
IT spending be analyzed against business value, and risks and returns fully evaluated

Whereas many of these steps deal with changing business processes and increasing understanding, there is one item that begs for tooling - being able to translate IT and business concepts. In my interpretation of this, it is important for IT to decrease the focus on technology and its "fads", and increase the focus on what the business needs. At one level, being able to mine a database for business data and/or infer new facts from existing data are critical - and whether the database is a relational, an XML, a triple or an object-oriented store is secondary and left to the interested reader to pursue. Oftentimes, we technology folks put the focus on the implementation and not the bsuiness. I would argue that the implementation doesn't really matter (and could/should be changed based on understanding risks and rewards) as long as the business gets the answers that it needs in a timely manner.

Now, on the business side, there is a need to formally capture and "debug" business vocabularies, rules, processes and related data to improve their quality, and decrease the communication mismatch between the business and IT. For example, tooling can take business vocabularies and create relational or object-oriented models, or XML schemas, that are more natural forms of communication for computer-inclined personnel. And, business rules and processes are captured today - although usually in arcane and obscure computer languages that mean nothing to the business people. There could be a two-way translation between a business person's natural language and these rules and processes. What a concept!

I know that people are working to change this. :-)

Andrea