Archive for July, 2016

The Future of Insurance Company Data Infrastructure: Microservices

Thursday, July 28th, 2016

We’re often surprised to discover that there are insurance companies that haven’t yet transitioned to a new IT infrastructure including real-time data and strategic decision-making. These are all types of insurance companies, not just small ones, that are doggedly tied to legacy systems and run by leaders who are afraid of change. On the other hand, sometimes insurance companies want to transition to better systems, but they don’t believe they have the IT dollars required to make it work. They are afraid of investment in new data platforms.

download (1)

Build IT Infrastructure

The truth is that firms like ours can build any kind of IT infrastructure that an insurance company wants without them having to discard their legacy systems. This comes as a surprise to some, and, in the long run, helps insurers manage costs while adding data capacity. All it takes is a careful analysis of an insurer’s existing data infrastructure and a two-way dialogue about its present and future data needs.

Think Microservices

One way that we help insurance companies increase their data capacity without abandoning their legacy systems is through development of microservices. There are many ways to explain this process.One comes from Forbes.com writer Ben Kepes:

“Organizations are increasingly moving away from a monolithic approach to the way they build applications and looking to much more flexible, modular approaches. The rise of microservices, distinct application modules responsible for a single operation within an application, has been helped, and has also itself helped, the parallel rise of containerization as a way of creating infrastructure.”

Break It Down

What’s monolithic? Well, in the past, many businesses used one suite of business applications, often called enterprise business software solutions, for all of their data needs. This kind of system was equipped to carry out all computing functions, including HR software, accounting software, and customer relationship management software. These systems were considered monolithic because they did not integrate well with other applications. That’s really not how the business world works anymore because we can create solutions that talk to just about any proprietary system your insurance company presently uses.

At this point, you might be thinking: “Okay, microservices are smaller, and they don’t depend on their integration with a larger suite of applications, as in traditional enterprise business systems. But what do they really do?” We can make a microservice do just about anything that your company needs it to do, either to meet the needs of subscribers or to manage internal business processes.

We’ve Got Answers

We are experts in building microservices, and we can help your insurance company find the right solution. We specialize in the software architecture style in which complex applications consist of small, independent processes communicating with each other using language-agnostic application program interfaces (APIs). This means that the solutions we create will not depend on any specific programming language to work. We can use the API for any system that your company uses to exchange data with a new microservice. We build it just for you to your specifications. Or, you can request an application like one of your competitor’s uses. We help you add data processing capacity one microservice at a time, if that’s what you desire. Or you can add a whole set of microservices because you want all legacy systems to offer the same benefits as newer insurance platforms running on the latest technology.

We can help you move in stages towards having better IT applications at your immediate disposal, usually working on real-time data. It’s important for your company to manage subscriber protected health information (PHI) and other data with care and in conformity with tighter government regulations. For more details on microservices and how they help your organization, please contact us today.

Managing Changing Priorities During the Agile Software Development Process

Thursday, July 21st, 2016

Speed and functionality are the driving forces behind agile software development process. Within an agile scenario, small teams  rapidly deliver functioning product within a short time frame. These outcomes are achieved when teams are given flexibility and self-governance. However, even the most independent agile teams must bow to customer demands and changing markets. So, what do agile teams do when priorities change?

They default to their agile processes. Indeed, agile methodology has change management in its DNA. Here are the agile processes that your team can leverage when change is afoot.

High_speed_rail_23471432

The Development Cycle

Agile methodology speeds up the development cycle. Instead of completing each step at a time, all steps are taken on by various team members simultaneously. Through timely communication, regular check-ins and a focus on adaptability, the team attempts to create a functioning end product within a set time frame, usually three weeks.

If the product isn’t functioning in three weeks, then the development phase of the cycle begins again. Each new beginning marks the beginning of a new iteration, or sprint.

When it comes to managing changing priorities, early phases of the development cycle are important but the end of a sprint is critical.

Agile Phases

Most agile team leaders agree that establishing clear goals and transparent metrics keeps all stakeholders, including customers, aware of progress and facilitates collaboration. During the first phase of the agile process, goals are clearly established between all parties involved. This is done by determining the project’s feasibility, which is then followed by the next phase: planning.

During the planning phase, stakeholders determine how expectations will be met, and when. The team establishes the protocol and forecasts reasons for potential changes in priorities. Here are a few reasons why priorities might change:

  • The client might not be aware of what they really want but suddenly figure it out mid-development.
  • The marketplace undergoes unexpected changes.
  • During the testing stage the client finds defects and missing features.
  • Regulations and security features might change, especially for those in heavily regulated and data-intense industries.

Discussing these potential scenarios with the client gives the team a chance to explain how agile methods are designed to address changes in priorities.

After planning, the team dives into development. Development strategies are dependent on the type of team, product, expectations and plan, however, the meat of development is the same across projects. According to Gregory S. Smith, author of Becoming Agile, development involves building, testing and demonstrating product features. Yes, demonstrating. At the end of each iteration, all stakeholders meet face-to-face and participate in a demonstration of the project.

Then, priorities are officially changed. In other words, the agile process includes, invites, encourages a priority shift every three weeks (or the time determined by your team during the planning stage).

What Could Go Wrong?

If not handled appropriately, then shifting priorities might mean that your team will experience a backlog of unfinished tasks that continually get moved down the stack.

How to handle shifting priorities appropriately? This can get tricky as each stakeholder has different priorities. Developers might have solutions that the client thinks are too costly or time-consuming, usability designers might want to push ahead and prioritize other elements that are related to their tasks, while upper level management might be concerned about timelines and expenditures.

Ultimately, if all stakeholders are unable to reach a conclusion, the Scrum master, or product owner, or product manager (there are a variety of titles for the person in charge) has to make a decision. This person is usually part developer, but mostly part business analyst.

The business analyst/product manager must determine how to make the customer happy, how to deliver a quality product and how to nurture talent. It’s not the easiest role to have in an organization, but a good product manager is able to balance the needs of all parties and manage priorities while keeping to the established timeline.

In most instances, the team is able to self-govern successfully, stick with the plan that was devised early in the project and deliver the best product in the shortest amount of time. To find out more about agile methodology and how to manage priorities, please contact us.

Trends in Life Insurance: What Consumers Want Impacts Insurers

Wednesday, July 13th, 2016

It’s hard to think of any company as being on the cutting edge of the insurance industry. Why? Because of so many rapid advances in every economic sector, the modern insurance organization struggles to keep up. Since the institution of Obamacare, insurance companies have struggled to update their information systems and business practices to adapt to a consumer-driven environment. They also face stricter government regulations. In reality, life insurance companies belong to the same group as health insurance companies in the sense that they collect medical information about subscribers. You might be wondering how all of this ties together. In a nutshell, these kinds of insurance companies must deal with the fact that 21st-century seniors are living longer!

Consumer

Consumers Always Want More

Today’s seniors and middle-aged consumers planning for retirement share a common concern. They want to ensure that their life insurance policies and annuities will stand the test of time. Quite frankly, we just aren’t sure if we might live to be a hundred years old. If we retire at 65 and live to that age, we need money to survive for 3.5 decades. Recently, we were reading Greg Ostrowski’s piece on the U.S. News & World Report website. From the standpoint of trends in life insurance, we believe it offered some helpful insights for insurers trying to understand what consumers want, which should always drive their designs for new or improved customer service platforms.

1. Consumers want to take stock of their existing collection of retirement products. Ostrowski explains that this can include considering their 401K plans from former employers, their stock portfolios, and their retirement savings accounts. He recommends that people evaluate their assets and liabilities. Anyone who has tried to buy a home or to refinance student loans has thought about this at some point. What about everyone else? We would add that insurers marketing to consumers must address the concern of having enough retirement income. They must shape their financial products, including life insurance policies and annuities, to fit this environment.

2. Consumers must plan for retirement savings and for retirement spending needs, says Ostrowski. This is a no-brainer for insurance companies. A good life insurance website includes financial tools for consumers to use to make calculations, especially estimating future payments and retirement expenses. At a minimum, retirees require some money in their budget to visit their grandchildren.

3. Consumers can plan a budget that takes into account the timing of different retirement payments. In the same month, this could look like Social Security income, dividends from stocks, payments from annuities, and payments from employer-based retirement plans.

4. Consumers should understand the tax implications of different types of accounts, not just the timing of payments (i.e. IRAs and annuities). Information about these kinds of questions are ripe for featuring on insurance websites and subscriber account management platforms. These should be updated when the federal government creates new tax regulations.

If consumers take into account all assets and liabilities, formulate a budget, and then purchase financial instruments that provide enough retirement income, they will still have other worries. A big one, says Ostrowski, is what they will do with their cash. Some might think of this cash as “running-around” money, and others might think of this as money to save for their heirs. There are so many options for spending cash, everything from playing the stock market to acquiring more real estate.

We have many ideas on how to build consumer-friendly information systems that fit a life insurance company’s existing infrastructure. We aren’t necessarily tied to the wraparound approach. We can go to the drawing board and create entirely new information systems upon request. If you have questions about how to build web-based systems that benefit subscribers and prospects in the consumer-driven economy, please contact us.

5 Common Problems in the Agile Software Development Process

Thursday, July 7th, 2016

Agile software development teams work through a series of sprints to reach project completion. In the beginning, the product owner ensures that every part of the project is well mapped out and assigns duties to each team. More than one team may work on the project at any time and the people on each team may change during the product development cycle. That’s why it’s important to understand the common problems in the agile project management process, and here we break down five of them:

635958305651591831-1074145117_Communication

Problem 1: Communication breaks down between teams. These teams include individuals with vast technical expertise, but sometimes they just don’t communicate well with each other. The product people are about preparing the product for the market, and the software engineers are deeply enmeshed in the details of building the client’s service-oriented architecture. If they could just work together, the project would get done faster. The product owner does not have time to resolve all of the communication issues between teams while managing multiple projects.

Problem 2: Knowledge silos hold up progress. People on one team are specialists in certain aspects of software development. They know their coding techniques inside and out, but it may be hard for them to understand the technical components that other teams are working on at the same time. Everyone wants their own share of the project to be superior, but it’s easy for multiple teams to forget they’re working on the same product. In reality, their sharing of technical knowledge would benefit everyone on the project.

Problem 3: Historical knowledge wanes, and agile teams start holding meetings without understanding their relevance. In the beginning, the product owner laid out a plan for the sprints that agile teams would move through to complete the project. If there is difficulty completing one of the sprints or if teams waste too much time on sprint reviews and retrospectives, the entire project stalls. The final product may diverge from the version defined by the product owner.

Problem 4: Quality assurance is not built into the development process. Some people assigned to agile teams have experience working through this process, and others are newer to their respective teams. What’s more, some teams work better together than others. However, the project depends on each team meeting its deadlines and producing quality pieces of software. Agile teams should have a system for documenting that the customer is happy with the completion of each stage of the project. Quality assurance documentation occurs in the background throughout the project even while agile teams push forward to achieve their sprints on time.

Problem 5: Location affects the ability of teams to collaborate on the project. What happens if one or more agile teams are working from different locations? It’s not like they can run across the hall to discuss problems with writing code or bugs to work out after testing has been completed. They have to find ways to work together throughout project management software, through emails and video conferences, and through telephone conversations. Even if multiple teams can conference together on the phone to solve project issues, this takes everyone away from the work they must do to complete their team’s assignment.  

The agile software development process is full of potential issues that hold up project completion. The best agile teams work together to complete their work on time and communicate effectively with other teams. If you partner with the wrong firm to build a service-oriented architecture for your insurance company, you could wait weeks or months and still get an inferior product. We have our risk management and quality assurance methodologies in place to ensure that our agile teams complete all work to your satisfaction. We solve technical problems before they affect the final product. Please contact us today for more information.