Case Management Pattern for Process Modelling

Most organizational business processes follow the Case Management Pattern.  Any governmental program involving an application, request for service, licensing, and more will sit on top of the case management pattern.  We have compiled features and functions from dozens of case management projects over the years.  These features and functions are best understood when organized into a framework that aligns with the Agile concept of Themes.  There are ten Themes; for each Theme the features and functions are organized into ten major topics.  This reference model serves as a useful checklist to evaluate the specific needs of the business areas you are investigating.  Each Theme includes a high level business process model.  You can modify these models to prepare the Straw Models to begin your requirements workshops with your project's subject matter experts.  You will discover that most government programs follow the reference in this document; what is unique are the decisions, business rules, and data inside the process, but not the process itself.

Case Management Reference Guidebook

Business Analysis takes Nine Months

It takes time for the system integration vendor to figure out the complexities of the client's business to determine the real opportunities, challenges, and appropriate use of technology to enable achievable improvements in processes and employees’ work satisfaction.

Unfortunately, time is money for vendors so project budgets and company finances cannot afford long gestation periods for the business analysts to produce the specifications that enable software development to begin.

The vendor needs to move quickly through the business analysis because:

·        Developers can’t be scheduled far in advance with any reliability;
·        Project management is expensive; this is a fixed cost. So the fewer months that the project takes the less the cost per month for project management on a fixed price project.
·        For a fixed-price project it is more economical for the vendor to have five analysts for three months than three analysts for five months—or two analysts for seven months. 

But no increase in the number of analysts will compensate for the amount of Time needed to absorb, reflect, and fully align activity with understanding and opportunity.

But the longer the analysts are working with the client before developers arrive, the greater the depth of understanding, the greater trust level is achieved for effective communication, and the more nuance is gained on how to design new processes and align work with the preferences and potential of the client’s staff.

The longer time period of analysis, even with a skeletal crew, enables seeing a wider range of events that may occur infrequently, the more specialized processes are detected that are not reveals in requirements workshops or casual walkthroughs of the clients warren den of cubicles.

Options

Our preferred approach to enabling a longer time period for business analysis (with a small team) is to have analysts embedded with the client’s staff performing data readiness.  We strongly advocate taking a year or longer to go through the legacy databases and interfaces to assess the status of data that may need cleaning up and to determine how to handle missing relationships when older database designs will be replaced by modern relational databases.

As described in other papers, an internal project to assess and do the work to understand and fix deficiencies in existing databases can be done by internal staff with minimal outside support.  This makes it possible to spend a year gaining in-depth familiarity with legacy systems using internal, existing funds while working to obtain budget for the desired new solution.  The data fixing effort can include a business analyst who works with the lines of business to understand the procedures they have followed that may have inadvertently led to some of the bad or missing data. 

During the time the data readiness effort is underway, the Sponsor can have a team undertaking business analysis to document business processes, decisions, business rules; evaluate the activities that exist due to limitations of older technology, opportunities to streamline processes with technologies that enable best practices, re-define workload measures, and more.

Four Phases to Enterprise Business Architecture - WIP

NASCIO provides the foundation for the proposed four phases:
1. Environment and Context; products, services, workload measures, Stakeholder Context Diagram
1P. Political Architecture: Unions, organized constituencies, Voting blocks, legislative committees, competing solution constituencies
2. Organizational intent: legislative mandates, business processes, Decisions, Business rules
3. Enablers: Functions, Staff Skills baseline,
4. Target Operational architecture: Concept of operations, Target staff skills and work organization, Patterns, Key performance Indicators, best practices,
5. Roadmap: Needed training, needed organizational alignment, needed stakeholder collaboration,

Business Architecture Methodology

TOGAF and NASCIO provide best guidance for what goes into the enterprise business architecture; references to the FEAF and Zachman are needed reference to get the most from TOGAF and NASCIO. In coming months am going to offer some refinements to NASCIO and TOGAF and include some sample artifacts. Methodology effort will address the challenges of limited staff time, massive scope, how to break down the activities into logical chunks, and making the results ACTIONABLE. There is too much inward or narcicssitic effort in architecture: focus on what is personally important rather than what will help move the business and technical investments forward to deliver solutions faster, better, and cheaper.

Business Interaction Model

The Business Interaction Model defines six interactions between the customer and the "System". The Model is a graphical depiction of the interactions of the Customer with the System, the applications within the System, and the System's interactions with external Suppliers. The key contribution of the BIM is the "Customer Interaction Stack":
Recognize the Need/Want
Research Options
Inquiry: Establish Contact, understand offerings, prepare offer
Contractual Phase
Delivery/Fulfillment
Completion: Audit, appeal, satisfaction assessment.

The point is these six interactions occur whether they are formally recognized or not. The lack of recognition and measurement for each interaction suggests a deficiency in the enterprise's service delivery capability and accomplishment.

For the Business Architecture, we make the hypothesis that a Business Service performs one or more of these six interactions.

We are still looking for clear definitions to distinguish between a business function and a business service.

The Business Interaction Model is a way to discover functions, events, and roles that contribute to needed business process analysis/models, business rules, use cases, and the business architecture.

Introduction to Contributors and the Curious

Welcome to a forum for business architecture practitioners. We will explore essential topics in business architecture: what is it, what are the methodologies and frameworks, best practices, experiences, lessons learned, relationship to enterprise architecture, contribution to service oriented architecture, and other related subjects you may contribute. You may recommend articles, publications, other blogs, web sites, conferences, and books. Please encourage your colleagues, clients, and consultants to contribute to this site. If you can recommend a better site already in existence, we can simply turn our site into a hyperlink to a better location.