GR: Can you give our Members an example of an organization you worked with where the application of the Business Architecture practice made a difference for them?
SL: A few years ago, I worked as a Business Architecture consultant for a health insurance provider. The insurance business, and health insurance is no different, is driven by rules. For example, if you’re in X insurance plan, then you have access to X benefits, you pay X amount in a premium, X amount is your copay, X amount is the maximum limit of what the insurer pays. And, under certain circumstances, you may also have these other benefits such as if you’re a woman, then you may have maternity related benefits. And, we may cover X procedures, but only with pre-approval, and if your doctor is in our network then we may cover more, otherwise we cover less.
So, anyone who has read his or her insurance plan brochure in detail, which is never a fun read, you know that there are lots of rules and also lots of exceptions to the rule.
When you go to see a doctor for an exam or a medical procedure, that doctor then submits an insurance claim to your healthcare insurer, and that claim has to come in, follow a certain process, has to be adjusted, and then has to be verified before it’s paid. It used to be that claims were mailed in, were submitted on paper, and verified manually by human claims processors and interestingly enough, some claims are still mailed. But, the majority of claims are submitted electronically and they’re parsed electronically, and the systems that ingest them electronically were developed in stages over a long period of time. The result of that is that most insurers have inherited a patchwork of systems, some of them are still mainframe based and developed in cobalt, others are very new, and each one of them covers a few steps of the overall claims processing workflow.
When the first systems were developed, 30 – 50 years ago, the rules governing the health insurance business were simpler, not as involved and circuitous as they are today, and the software developers that created them hard coded the rules, meaning they programmed them directly into the code. Now, these rules have changed and as a result, sequence of alterations have been made to the original code and, in many cases, without proper documentation. So, in addition to having this patchwork of systems, insurers also have legacy systems where the code is tenuously maintained because none of the original coders are still around.
In these types of situations, you pretty much have no choice but to bring in Business Architects to document the business. In many cases, this is done by sitting down with the veterans in the organization, the people who’ve been around the longest, who know how the business is done, and interviewing them and essentially extracting this institutional knowledge out of their minds and documenting it in different types of models. These models have to be detailed because the reengineering system that’s necessary to accomplish the digital transformation for the organization starts with these models. You don’t have other documentation, it starts with the models, and with the business rules so. In essence, what you’re doing is you rebuild the data and the system architecture of the organization from the ground up, starting from the business layer.
And this is what we did at the particular organization that I mentioned previously, where the decision was to acquire a Pegasystems package built for health insurers, and to configure the package to align it to the process models and the business rules for this organization. It was a successful endeavor.
GR: You were making me think back to the early days when we had first launched the training curriculum from the Institute, we had a set of courses called ‘Business Rules’ and that morphed into ‘Business Decision Management’. Today, in its latest form, it’s part of our Digital Transformation curriculum, and it’s now called ‘Decision Automation’ and we do a lot of work with James Taylor who’s a well-known author and subject matter expert in that space.
The business rules needs are still there. Earlier this year, we conducted training with a couple insurance companies and you’re right, they’re still trying to get the business logic out of the code and out of the old systems. So, they have much more agility and flexibility on handling things that are going to be coming down the pike including mergers and acquisitions.
Editor’s Note: This is a five-part article and video series.
Watch the entire Top 5 Things to Know About Business Architecture video series
Read the other articles in the series here:
Article 1: What does Business Architecture Mean for You?
Article 2: Do Organizations Understand the Value of Business Architecture?
Article 3: What will Raise the Profile of the Business Architecture Discipline?
Article 5: What does the Future Hold for Business Architecture?
