When consulting on software projects, there is a common question many Enterprise Architects may ask of product owners: “What exactly are you trying to accomplish?”.  All too common in software projects is the scenario where business analysts and product owners, when considering system requirements, are most concerned with what happens when this button is clicked, does it call this system, or that system, what does this screen look like, or what happens when I click the back button in a web browser.  In other words, too much emphasis is placed on capability, rather than solving the business problem at hand.  A very important step in these projects that is all too commonly overlooked is an examination of the business function being implemented, including an analysis and detailing of the related processes and the milestones necessary to achieve the goals of these processes. This examination must be completed in order to effectively answer the question of how a software implementation can help augment, scale, or otherwise enhance the business function.  This examination is a key component that can and should be described under the Business Architecture aspect of the overall Enterprise Architecture.  The goal of this exercise is to convince Business Analysts and Product Owners to forget IT and software and focus on the business process and the business goals.

A term often used to describe the roll-out of the federal health insurance exchange hosted on Healthcare.gov is the word “rocky”. An Enterprise Architect might instead use the word “fragmented”, in that many of the issues surrounding the site can be attributed to a fragmented approach to the project requirements that is clearly the result of having never asked the question, “What exactly are you trying to accomplish?”, or having provided a clear response to that question. Many of the issues, that have by now been well-publicized, would have been easily avoided, had the project started with a clear business architecture, completely unrelated to anything involving software or information technology.  By focusing on the business problem first, and defining the goals and processes for solving that business process, each proposed step in the implementation of that process, be it through Information Technology or manual processing can be justified by its role in solving that problem.  Any proposed capability that cannot demonstrate a clear objective in solving the business problem at hand should be excluded from the eventual implementation.  Therefore, when considering the roll out of the healthcare.gov website, consider the problems that have been identified with the site, and ask the question: Can the capabilities that are causing these problems with the website be justified by their role in solving the business problem at hand?  The results of this simple question are staggering.

In order to illustrate the importance of Business Architecture in an Enterprise Architecture, consider the Enterprise Architecture Development Life Cycle defined by the TOGAF framework for Enterprise Architecture:

Source: The Open Group Architecture Framework: http://www.togaf.org

Under the TOGAF life cycle, an enterprise architecture begins with a preliminary framework and principles. In the case of the Affordable Care Act, the law itself provides this foundation. The law clearly specifies a framework for the principle goal of making healthcare more affordable. The law also provides for an “Architectural Vision” defined as the second step in the TOGAF life cycle, whereas part of the law clearly envisions a marketplace where Americans can shop for, and purchase health insurance. The third, fourth, and fifth steps in the life cycle, where the business architecture, information systems architecture, and technology architectures are respectively defined is where, in the case of the healthcare.gov exchange, the life cycle begins to break down.

In the rush to implement the healthcare.gov exchange, the business architecture step was very clearly skipped, or at the very least, not given due diligence. As a result, the goals of providing an Information Systems Architecture have been mixed or confused with the goals of providing a Technology Architecture. Compounding the issue is President Obama’s decree that the “Best and Brightest” have been brought in to fix the issues with the site. When considering the TOGAF life cycle, what the president described with this decree is a focus on the “Opportunities and Solutions” phase of the life cycle, and possibly the “Architecture Change Management” phase of the life cycle. This focus may provide a series of band-aids of various sizes to the technology implementation of the federal healthcare exchange, but does not address the root cause, which is the failure to provide a coherent business architecture for the implementation of the federal exchange.

In providing a business architecture for the implementation of a project such as the federal and state healthcare exchanges, it is important to define the goals of the enterprise, and derive a process pipeline that results in meeting those goals. Within the process pipeline, major milestones are defined, and it is from these milestones that the individual business components are derived. Consider the process pipeline for obtaining health insurance under the Affordable Care Act:

Copyright Virtual Interworks, Inc 2013

The process pipeline is frighteningly simple.  An individual who wishes to enroll in an insurance plan through the exchange fills out and submits an application, the eligibility is determined based on family size and income, the applicant selects coverage, the application is forwarded to the insurance carrier for processing, and coverage begins.  Each item in this pipeline defines a clear business component of the process pipeline, whereas each component implements a process within the pipeline.  Each process in the pipeline has a goal that must be met before the next process in the pipeline can be initiated (e.g. eligibility cannot be determined until an applicant has filled out an application).   Most of the issues surrounding the healthcare.gov website are related to the first process in the pipeline, which is the process of filling out an application.  More specifically, the media frequently mentions the “Data Services Hub” and “Identity Verification Service” as frequent causes of issues with the site.   This is an important fact when answering the question, “What are you trying to accomplish?”.  In other words, what is the goal, and what needs to be done to accomplish that goal?

The goal of the application process is for someone who wishes to enroll in a health insurance plan through the exchange to provide the personal information required to obtain health insurance.  This goal, as well as the information collected to achieve this goal remain the same, whether the applicant is applying online through the healthcare.gov website, through the mail by filling out a physical form, or by meeting with a qualified Navigator.  Similar to the overall process pipeline for obtaining health insurance through the exchange, the business process for submitting an application is also frighteningly simple.  Regardless of the scenario, the process consists of two steps.  First, the applicant supplies the required personal information to a form, second, the applicant submits that form to the Department of Health and Human Services in order to initiate the next process in the pipeline, the process to determine eligibility.

When considering the simplicity of this process in the context of the question, “What are you trying to accomplish?”, a few questions begin to emerge:  Where in that process is the need to verify the identity of the applicant?  What step in that process is automated, scaled, or otherwise enhanced by the use of a “Data Services Hub”?  Are applicants who fill out and submit the paper application through the mail required to verify their identity before filling out each page or section of the paper application?  Is the information that applicants enter in to the paper application verified as they are filling out the application, or when the application is received?  At what point in the process pipeline does it become crucial to verify the applicant’s identity?  If the data services hub, among other functions, provides income data in order to verify an applicant’s stated income against prior tax returns provided by the IRS, which step in the process pipeline is it necessary to do so?  Don’t insurance companies already verify applicant information, including identity, prior to underwriting?  Doesn’t the IRS already verify income stated on a tax return against forms W-2, 1099, schedule K-1, etc?  If final tax credits are determined when filing a tax return, is it necessary to verify income at any part of the enrollment process?

The answers to these questions all lead to one common conclusion:  The “Identity Verification Service” and “Data Services Hub” that have frequently been blamed for issues with the healthcare.gov website are, in fact, not required, and completely unnecessary in order to achieve the goal of filling out an application. A paper applicant will not, in fact, be asked to verify their identity and income while filling out the application.  These services might become marginally important as part of the process of determining eligibility, but since eligibility is determined based on the information provided by the applicant under the assumption that the applicant has provided such information in good faith to the best of their knowledge, they could be deemed unnecessary during this process as well.  They are unnecessary during the process when an applicant is selecting a plan, whereas it is clearly stated that subsidy amounts are merely estimates, and the final amounts will be determined on the applicant’s annual tax return.  In general these services only become necessary at the point where coverage is underwritten by the insurance company.  Insurance companies already verify applicant information, often from the same source as the healthcare exchange (Experian).  Income verification may not be necessary at all, as the subsidy amounts provided by the exchange are only estimates, whereas the final concrete amounts will be determined on individual tax returns, therefore, income is already verified by the IRS when tax returns are filed.  A good analogy might be when an employee submits IRS form W-4 to their employer in order to determine tax withholding amounts, the information provided is not verified.  If false or otherwise incorrect information is provided, it will be reflected on that person’s individual tax return.  These facts support the conclusion that the “Data Services Hub” and the “Income Verification Service” are not necessary components to any part of the system.

When considering the importance of defining a clear Business Architecture prior to any implementation, we can conclude that the risks of not doing so can be costly, even catastrophic.  These risks include the risk that crucial business functions may not be implemented.  In the case of healthcare.gov, they include the risk that components may be implemented that are not required.  Coupled with the fact that it can be demonstrated that these components have been a cause for a near complete system failure, it can be concluded that the lack of a defined set of clear goals under a Business Architecture, and a strict process for justifying business components based on their function toward those goals demonstrates the crucial importance of defining and enforcing a strict process driven Business Architecture.