Gregory Maciag

Model Insurer

A new report from Celent highlights the use of industry data standards as a prominent best practice. According to Celent Model Insurer Asia 2012: “Model Insurers understand that they need to think beyond successful point solutions and create lasting systems that work within a larger infrastructure.

Using data standards means that an insurer avoids reinventing the wheel and instead manages risk by working with accepted, well-tested and well-defined models.”   Model insurers should work with models – neat.

Crafting the Perfect Insurer

Models Part 6: Moving Ahead With ACORD

I said that ACORD has a Framework development process that aims to ensure the Framework models track industry evolution. This is not to say that the ACORD Framework is a moving target, nor that organizations are obligated to shift to new versions of models as they become available.

We release the Framework models with careful version control, so that change is introduced in a stepwise fashion. And of course the change process involves staff working with our members.  Even organizations that choose to stay with one set of model versions gain a benefit that is new in our industry's history, and which is rare in business: they get to validate an industry view. Since changes to the models are incremental rather than revolutionary, this means that organizations gain valuable insights through evaluation alone.

Many ACORD members will use the Framework evolution as a guideline for their own strategic development processes, and others will choose to schedule version shifts as default activities. I believe all members will benefit from this mature and comprehensive set of models, and the processes we have put in place to ensure their continuing relevance. 

In this series of posts I've approached business models – and what we term the Information Model in particular – from the point of view of the management cycle. I've appealed to the idea that facts are central to management, and that facts are more than data. I've presented models as a means of organizing facts.

 My questions to industry practitioners are as follows:

• Do facts have the status they need in business?
• Do facts have meaning for technologists or are we drowning in data?
• Are you ready to articulate the facts at the heart of their business?
• Are you aware that we must manage the ongoing evolution of models?

 I welcome your thoughts.

Models Part 5: Managing the Evolution

The economist John Maynard Keynes is quoted as saying: “When the facts change, I change my mind”. Effective managers don't cling to a model when the model needs changing. Equally, an effective standards organization doesn't carve its models out of solid rock.

I began this series by talking about the difference between facts and data. I said that businesses need facts in order to manage well. Data are voluminous and variable; facts are relatively few and stable.  However, when we take a longer view, we can see that the level of facts evolves too. Facts mutate and facts become redundant. New facts are born – leading to new data acquisition facilities. We therefore need a level of management – a meta-management level, if you will – that focuses on the development of the models which the business uses to control its behavior.

We implement this meta-management level by using the same management cycle on the management cycle. We figure out what our goals are for the models, define the relevant facts, execute, and measure. At ACORD, we do this on behalf of the insurance industry. So, as well as publishing the Information Model and the other models in the ACORD Framework, we have a process for managing the evolution of those models. The aim is to track industry evolution.

In the next and final part of this series, I'll have a few words to say about the relationship between member organizations and the Framework evolution process, and I'll wrap up the series with some queries for you to ponder.

Models Part 4: Evolving Models

Business models sometimes meet resistance from managers who are not convinced of their utility. Some people don't “get” models like the ACORD Framework's Information Model because they're not clear on the distinction between facts and data. In the most worrying cases, managers mistake the data they happen to have for the facts they really need. Luck and momentum can combine to keep organizations moving along profitably on this basis. Sooner or later, however, the shaky factual basis of their activity leads to failure.

Other people are wary of models because models can look rigid and static. At first sight, any structure that claims to describe a piece of business will look like it's trying to set something fluid in stone. To describe, for many people, is to destroy. They believe that anything we say with certainty today will be wrong tomorrow. 

I empathise with this attitude. But there is an inherent danger in adopting any model – the danger of freezing the business to one version of the model. I can also see that doing so could be seen as a worse error than using no model. If you're not using a model, you stand a chance of succeeding despite having a loose grasp on the facts. If you use a model that's perpetually drifting into error – becoming the wrong model – then you lay your self open to much more culpable failure.

The solution to this dilemma is to rethink what a model has to be. The downsides of models that we've just looked at are all implications of a static, once-and-for-all conception of modelling. But models don't have to be like that. They can evolve too.   In the next and part of this series, I'll look at how model evolution can be managed.

Models Part 3: Building Models

In the previous post in this series, we looked at two examples of facts that would figure in any commercial organization's model of its world, whether or not that model was ever written down. But how many facts (remember, facts are different than data) is an organization interested in? Twenty? Twenty million?

Facts tend to self-organize into groups and hierarchies. So, for example, you could place the fact of the White House's zipcode in a structure of facts about addresses, which could be further embedded in an array of facts about traffic routing. When we articulate the environment of a business in terms of facts, we are building a model of what interests the organization.

Such models are, for unfortunate historical reasons, usually called “data models”. As we have seen, they would be better termed “fact models”. At ACORD, we document and organize our industry models within the ACORD Framework. We have a data model in the software architect's sense of the term. But we also have an Information Model, which is a model of the facts relevant to the insurance industry.

This Information Model defines the common vocabulary of the industry. When I say “defines”, I'm talking descriptively, not prescriptively. In other words, the Information Model reports the facts that the industry uses in its management processes. It doesn't stipulate those facts. The analogy is with the English dictionary. The English dictionary doesn't tell you what the words of English should be, but what they are; and dictionaries are updated to reflect the evolution of language in use.

Working with a model of facts like the Framework's Information Model, managers can be sure that they're asking meaningful questions and acquiring actionable answers. In the next post in this series, I'll have more to say about the evolutionary nature of our industry, and how models cope with evolution.

Models Part 2: Facts & Data

To manage a business effectively, you need to have a solid grasp of the facts in your domain of operations. You'll collect data that answer your questions about the domain and measure the environment's responses to the actions you take.  Every business will ask different questions, make different plans based on the answers, and execute their plans differently. The data they have will be different. But many of the facts they use will be common to them all.

For example, one company might gather data about the age profile of its local market. It could use this data to design a product for the largest age segment. This company defines its product and the target segment in its own terms. However, “product” and “segment” are concepts that travel outside the company. The company's understanding of “product” has to match that of its customers and competitors. Its understanding of “segment” has to match that used by the marketing community in general.

Note that this doesn't mean there is, for example, a standard market segmentation that everyone must use. Every organization is free to slice up the market however it sees fit. The commonality comes into play when you start comparing segmentation schemes with each other. They're all different – but they're all segmentation schemes.

Similarly, on the product side, a sector doesn't have to have a rigidly defined product portfolio common to all players. But the sector is likely to share the outlines of a product category scheme. And it will certainly share a core understanding of what “product” means in the sector.  In the next part of this series, I'll look at how facts like these are organized into models, so that they can be used in effective management processes.

Enterprise Achitecture Belongs to the Business

I'm indebted to Michael Denis for this:  Dr. Pallab Saha, professor at the National University of Singapore, Institute of System Sciences and self-proclaimed EA [Enterprise Architecture] Evangelist) has a running debate on the Enterprise Architecture Network group of Linkedin on why EA should not reside in the IT Department. His top six reasons are:

6. Notwithstanding history and evolution, EA does not equal IT Architecture.

5. True EA leads to redistribution of authority and reallocation of accountability, both beyond the CIO’s jurisdiction.

4. EA value proposition and benefits are solely business realisable.

3. The primary goal of EA is to build coherent enterprises, not better IT systems.

2. Organizations are complex adaptive systems, hence holistic synthesis takes precedence over fractional analysis.

1. EA failure is a business organizational failure, not an IT failure. Resistance to EA is a consequence of failure, not the cause of it.

Denis adds: “The natural fit is for EA to reside within the business and not IT.”

Business Must By Dynamic

Models Part 1: Facts

There are many ways of defining management. Some of those definitions get mixed up with leadership and others get confused with bureaucracy. I'd like to offer this definition of management: The continuous process of aligning intention with facts.  Management is about understanding the world you operate in, forming a plan about engaging with that world, executing the plan, and measuring the outcome. You then go around the cycle again.

Now, facts are hard to come by.  A fact is more than a piece of data. Data isn't hard to come by at all - we're drowning in data. Facts are data that are tied to meaningful entities. So, “1600” and “20500” are two pieces of data. They could be sums of money in a list of transactions. Or they could be elements of the White House address (1600 Pennsylvania Avenue NW Washington DC 20500). Data give answers, but only in the context of facts.

Facts and intentions are bound up with each other. Since a fact is data that responds to a question, you need to be asking questions if you're gathering facts. The questions you ask will be based on what it is you're trying to accomplish. Analysis of the domain you're interested in is closely connected with your intentions for that domain.

Sometimes, gathering facts is a way of gaining an overview that will allow you to make more targeted intentions – and thereby gather more specific facts. In any case, when the facts are in, you will take action, and measure the effect by gathering new data.

What I've described here is the classic management cycle: set goal – take action – measure feedback. I've described it in the way I have because the “measure feedback” stage depends crucially on the nature of facts. Unless you have a clear understanding that facts are more than just data, your management cycle can spin off into a parallel universe. You can end up approaching the wrong markets, fixing non-existent problems, or promoting symptoms over causes.

The way to avoid this danger is to have a strong articulation of your domain in terms of facts. In the next post in this series, I'll outline what that strong articulation must be.

Business Models - A Valued ACORD Asset

Wisdom has it that the most important asset of any business is the people. But we rarely unpack what that means. Obviously, organizations need people to get stuff done, although some dream of fully automated organizations where no product or process is touched by a human hand. A cold analysis of the value of people might find two main components: there's what people do, and what people know. These two components are related.

If managing effectively is a matter of doing the right things and doing them right, then marrying knowledge and action must be at the heart of running a successful business. Creating such an organization is hard work. It takes time and energy to build a great team, to keep it on track, and to evolve its knowledge capabilities.

In today's business environment, there isn't the time to nurture new business units over several business cycles. The nature of modern business opportunities means you only get one shot. So businesses that want to expand need some way of reproducing the virtues of their people – their knowledge and activity – that's instant, reliable and portable.

Happily, there's a name for the required artefact. It's called a business model. A business model tells you (crudely) the inputs, outputs and transforming processes of a company. For investment purposes, such a model will be quantified in terms of money. But for management purposes, the model must also be described in terms of knowledge and activity. The way this is done is to detail the data and processes that comprise the business as a system. Notice that this way of modeling says nothing about computers, despite the computing terminology. We're just looking at what the business needs to know and do in order to meet its objectives.

If you were creating a business plan for a new venture, you'd find a plethora of resources to help with the money version. From spreadsheet templates to plan-in-a-box solutions, there's no shortage of blueprints to help make a sound case for investment. Curiously, there isn't an equally mature set of resources on the operational-descriptive side. The lack of credible and comprehensive non-financial business models means that every time a new business or business unit is conceived, the leaders have to mine their own experience rather than referring to a blueprint. They must also focus on attempting to release relative expertise that's latent in their people, without having any objective map to orientate them, or any indicator of how thorough the knowledge extraction process is.

Enterprises know they can't afford this costly and risky way of doing things. They seek to “can” as much expertise as possible. Lately, the rise of knowledge management as a discipline has helped to ensure that fewer wheels get reinvented.

However, not enough decision makers in our industry realize that the descriptive business models they need actually exist. The ACORD Framework is a complete business model for the insurance industry, articulated in a family of complementary views. It has evolved from several industry initiatives going back many years, representing many centuries of combined expertise. It has been validated by the industry, and there is an industry process for maintaining it. It is, quite simply, the set of blueprints that every insurance company needs whenever it's considering setting up a new line of business, entering a new market, or altering its operational repertoire in any way.

The Framework talks about data and process, but that doesn't make it a software spec. Think of it as  the counterpart to a financial business modeling toolkit. Far from being a technologist's tool, it's the only artefact I know that actually serves the vital “people” aspect of business. The Framework is your key to the knowledge and activity that drives your business – and the fast route to agility.

For more information about the ACORD Framework, including the Capability Model, send us an email.

Architecture Matures

I've been looking at Robin Bloor's ideas about Information Oriented Architecture (IOA). He's on to something.

Bloor isn't setting up a new acronym for the sake of it, or trying to capture some of the luster of Service Oriented Architecture (SOA). What he's done is to think about how modern enterprises need to manage their data, and used SOA's strategy of embedding best practice to provide a strong management framework.  So, for example, data governance is built into the IOA. This means that data quality and access become integral features of the enterprise's information store, rather than external policies.

Bloor has a solid track record in tracking and predicting the evolution of the architectural viewpoint in software. His thoughts on IOA will help to guide decision makers as they continue to strengthen and refine data's contribution to business success.

Data Integration Blog

 

 

Enterprise Data's Dirty Little Secret

"Management doesn’t want to hear about data models or data architecture. Management doesn’t want to hear about the investment that’s necessary in a data management infrastructure separate from the technology platforms. That’s just noise, right? So just go put the data on the box and give me a reporting tool already, right? I don’t care about metadata, I don’t care about semantic reconciliation, I don’t care about your data model. I don’t want to hear about the mechanics of it."

The ACORD Framework is a great tool for us and is already impressing many of our members. But in truth, there will be a day when we do not need to talk about standards and models.  Not unlike all the standards we use everyday in every part of our lives.  They just work.

Read the whole piece for the great dialog between Jill and Loraine in this pithy expose of "Enterprise Data's Dirty Little Secret".

 IT Business Edge

ACORD Models Revolutionary They Say

Here is a quote from a conversation between architects:

"My sense is that the ACORD Framework has the potential of becoming a revolutionary rather than evolutionary) step forward in providing an insurance industry-wide understanding of the data that drives the industry.  It could well become the Rosetta Stone that bridges the gaps between carriers, agents, brokers, intermediaries, reinsurers, regulatory and reporting agencies, and the service providers that serve all of these differing aspects of the insurance industry.  Each of these areas has its own insurance language, often unintelligible to others, and the framework holds the potential for bridging these gaps."

 

IBM Contributes IAA Assets to ACORD

Today, IBM contributed its Insurance Application Architecture (IAA) Business Object/Data Model and the IAA Product Specification Diagram (PSD) to ACORD.  This contribution will result in a single Information Model as part of the ACORD Framework for the insurance industry. This is a signficant contribution of IBM intellectual property assets. Now we are going to harmonize the contribution with our existing Model and publish Version 2 so we can begin mapping all ACORD Standards and Forms. Pictured with John Kellingtonn and me is Inder Gopal from IBM who made the announcement.)

Here is the IBM Press Release 11-04-2009

ACORD Framework Will Provide Holistic View

Some organizations make a conscious decision to design their operations as a holistic, “one-company” entity that shows the same face – and the same capabilities – in every geography and product line in which it plays.

Scratch any large, multinational company today and you will surely find a “One Company” project aimed at aligning disparate forces, leveraging economies of scale and sharing knowledge across departmental boundaries. The depth and political profile of these projects vary immensely, however, and in some organizations the “One Company” drive may be simply an efficiency exercise, or a branding project.

“One Company” organizations that take their unification missions seriously tend to be passionate advocates of standards, and often play key roles in the development and implementation of business standards. But this behavior does not always spill over naturally into business data standards adoption and targeted advocacy may be needed. ACORD is developing a Framework so that organizations can approach ACORD Standards holistically from an enterprise view as needed. This is a big game changer for industry standards.  You’ll be hearing me talk more about the ACORD Framework in the weeks ahead.

 

ACORD Standards Framework Explained

You may have heard about the ACORD Framework involving capability, process and data models.  You may question why ACORD is now beginning to approach standards-setting in a new way to develop standard business messages. You will be hearing much about Framework in the coming months. John Kellington (SVP) and Cliff Chaney (Technical Architect) give you the scoop. Here is the link to the video Framework

And here is the Framework PowerPoint.