Posts Tagged ‘SOA’

Getting the Most Out of Your Investment: Three Steps to Revitalize Your Legacy System

Tuesday, October 4th, 2011

Companies don’t need to “rip and replace” large portions of their IT investments in order to gain the set of features they wantBy taking a multi-phased approach to incrementally roll in functionality, organizations can benefit from quicker ROI without the costs and risks associated with “big bang projects”. This multi-step approach is a win-win for business and IT; business can reap the benefits of go-to-market features sooner and IT will be able to adapt to changes more quickly.  Here is our recommended three step approach to revitalizing your IT architecture:

  1. Leverage What You Can: Revitalization efforts have to be carried out with a focus on leveraging your existing architecture. Wrapping your existing assets in web services keeps some of the older technologies in play.
  2. Implement As Needed: Keep it simple and only add functionality that’s really needed. By purchasing pre-built components that augment your existing systems, you can add the functionality you want with minimum configuration and customization.
  3. Rapidly Build New Functionality: Once you’ve decided on the new functionality that you would like to add to your system, we recommend that you rapidly develop these applications using software development automation frameworks such as FAST 8x. By rapidly building SOA-compliant components, you can leverage modern technologies and get the benefits of development efficiency.

Once you have implemented all three steps, you are on your way to fulfilling immediate business needs while achieving long term architectural goals for the future.

Darwinism of Innovation: The Evolution of Automation and the Software Development Industry

Wednesday, August 24th, 2011

In 50 years, will we still have armies of programmers coding business systems for companies? Will it still be necessary?

In the history of industrial growth, the replacement of tedious production processes with automation is essential to the progression of invention and ingenuity. But we seem to have forgotten this key to innovation in software development. We are so caught up in creating new processes, new languages, new “big system” solutions to address the same old problems of tedious code-writing in traditional software development that we forget the true purpose of this industry in the first place – to replace tedium and inefficiencies of the paper-pushing era. We seem to have it stuck in our heads that software development is too complicated to automate.

The key to replacing expensive, labor-intensive and entrenched systems is not by engaging in expensive, labor-intensive big-bang projects, but in increasing productivity, flexibility, and function-leveraging. This is industrial Darwinism at its finest: instead of replacing one inefficient system with another, find a solution that eradicates the costliest, labor-intensive processes altogether. In short, creating dynamic software that will automate technical coding so that the user can focus on the functionality and conceptual use of the software is the true innovative key to the future of the software development industry.

Here at FAST, we have done just that. As a part of a four-person newly hired team of university graduates, we were assigned the daunting task of creating a fully functional application with FAST 8x in just four days, inclusive of training, configuration, building, and presentation. The exercise focused on showcasing how software development automation can achieve what normally would take a team of developers, analysts, and engineers months of code-writing to accomplish. None of us had any previous experience with software development; only one of us had any true technical knowledge of software design, and we were granted access to one engineer to assist us in the configuration process. By the end of the week, we had presented a production ready SOA based set of components that included 40+ database tables, 4 components, full user interface w/20+ business processes, 100+ web services, integration into other applications, 5,000+ test scripts (that are on a nightly regression cycle), technical documentation, and a how-to guide.

This proof-of-concept exercise is a reflection of what we’ve been doing for months on a larger scale with our life insurance client. In less than nine months, we were able to build an entire suite of legacy-replacing components which included 800 database tables, 35 components, full user interface w/25+ business processes, 700+ web services, integration into other applications, 13,000+ test scripts, technical documentation, and a how-to guide. This legacy system modernization process, which would have normally taken approximately three to five years to develop traditionally, is a remarkable step towards the breakthrough technology necessary to take software development to the next level.

If Policy Admin Systems Are a Thing of the Past, What’s Next?

Friday, August 27th, 2010

Last month, I shared the reasons why I believe large policy administration systems are a thing of the past.  As a follow up to that post, I would like to offer some insight into what I think the next generation might look like.

Certainly, the future solutions will leverage SOA and small re-usable components.  Here is an example of a life insurance financial transaction and how it can be constructed using a series of web services sitting on top of standalone components.    A series of discrete web services sitting on top of standalone components can be orchestrated to perform the overall transaction.  Typically this logic is buried in code somewhere, but by doing it this way, the components are decoupled.

It is fairly easy for people to describe and agree on what is needed, but pretty difficult to actually get there.  So, here is a brief explanation of the steps that can be taken.

  • Build all new components to be small enough and able to stand alone – All functions your components perform must assume all data is received from the outside.  They will only have access to read data that is specific to and contained within the component.  All other necessary data should be received as parameters.
  • Leverage an existing component when you can - To leverage your existing functionality, functionality needs to be walled off and you need to integrate with it however you can (not one size fits all).
  • Separate out orchestration – Using 3rd party software for orchestration forces a discipline to make the components truly standalone and guarantees the isolation of orchestration logic.  We use Microsoft Biztalk and IBM Process Server to do this.  However, there may be times for performance that you need to write code to have these components truly talk to each other.  This code has to be isolated into a separate level.
  • Find the right level of granularity, which can be an art – I have debated this point with people over the years.  On one hand, you can make every single method its own web service that can be orchestrated.  The other extreme is what most people have.  Like most things, the answer is in the middle and unfortunately case by case.  We draw the line at useful components that can do their own jobs.
  • Assume data can come from anywhere –The user interface, orchestration, web services and business process logic should not care where that data came from.  The data source should be abstracted from those layers.  In addition, the data translation needs to be handled “outside” your core code (either isolated in its own code or preferably in a 3rd party tool).
  • Continuously eliminate redundancy – There is no way to completely eliminate redundancy, but you can certainly try.  Purchasing existing components that have single functional purposes is the best way to start off with less redundancy.  However, you will still have to evolve and continue to find the places where there is redundancy and pull it out.
  • Use a modern “technology stack”– Wrapping your legacy keeps some of the older technologies in play, but if you limit its functional purpose, you are also limiting what needs to be maintained.  The newer components can leverage more of the modern technologies and get the benefits of development efficiency as well as scalable organization.
  • Implement as needed – Keep it simple and only add functionality that’s really needed.  It’s important to avoid the “bloat” of having every feature possible.  Only add components and functionality that is needed to run the business.  By stringing together the components that are needed, you can avoid having to maintain things you don’t use.

In the future policy administration model, companies can incrementally add functionality into their enterprise without major conversions and “big bang projects”.  The business can get benefits sooner and when the priorities change, you can adapt.

If you want to learn about the next generation of Life Insurance enterprise components, see

Tom Famularo

8 Reasons Why Large Policy Administration Systems Are a Thing of the Past

Friday, July 9th, 2010

Today, it’s clear that insurers will stop placing big bets on large systems. They’re moving to a model where small components and web services combine with their legacy components in an incremental manner. Here are some of the reasons why:

  1. All systems want to be the “center of the universe”. In a future world of SOA and architectures of small re-usable components across an enterprise, components need to be built from the ground up to be standalone and ready for integration.  Most vendors of “systems” or “platforms” say they are built for integration (and some of them even are). Of course, you need to make that system the “hub”.
  2. “Throwing the baby out with the bathwater” – much of what insurers already have in place works just fine and can be leveraged in some way without significant expense.
  3. The full software package has a number of awesome features that are just not applicable to your business.  It has been estimated that more than 50% of the overall functionality a system has to offer is not even needed or used in the average implementation.   The customer is paying for this functionality one way or another (with higher than needed fees to vendor and higher maintenance costs due to “code bloat”).
  4. There is no comparable “one-to-one” match to your existing legacy platform you want to replace.  So, a significant mapping, customization, “configuration” and integration job is required.
  5. Redundant functionality in the admin system to other areas.  Typical redundancy consists of client, product, policy, agents, and even generic functionality like content management, users, security, work queues, correspondence and much more.
  6. It’s all legacy anyway.  The “newest” US life Policy Administration system with any substantial customer base is about 10 years old.  With technology generations coming and going faster than ever, this is already out-dated.  Compound that with the fact that it will take you 3-4 years to convert your legacy onto this “new” system that is now almost 15 years old when you are finished…time to start looking again for a new system.   Now, let’s look at some of the other “good” systems on the market…they have all been re-branded by slapping on new technologies onto their old core code.  In those cases, you’ll be looking at a 20-25 year old system by the time you’re done.
  7. Instead of incremental improvements sooner, systems are designed to be implemented as “big bang” by converting full blocks of business or put up new products.  They do not allow you to implement one major business function at a time.
  8. Most of the top vendors out there have been acquired by a large company who has significantly increased costs, are primarily looking for the “big deals”, have stopped innovating, and diluted the domain expertise and talent.

If you want to learn about the next generation of Life Insurance enterprise components, see

Tom Famularo

LOMA Lessons: Going Agile

Thursday, June 3rd, 2010

Attending my first ACORD LOMA conference this year was an eye-opener. Whether I was chatting with someone in the exhibit hall or attending a session presentation, a common theme was apparent: insurance companies are tired of doing things the same old way.

Several people described system implementation horror stories – multi-year, multi-million dollar investments that hijacked IT organizations and created business roadblocks. Meanwhile, they acknowledged that maintaining their current stable of disparate legacy systems impairs their company’s ability to compete.

Clearly, something’s got to give.

Everywhere I turned, people were describing how going smaller was what they needed. Shifting design approaches from technical staff to business users was another common refrain.  Several presenters extolled the virtues of rapid development of “bite size” code, getting end users to quickly see what the results of their requirements are, and connecting them via SOA architecture.

One of the drivers of the shifting landscape has been some recent success. One large P&C insurer described how a small series of components developed in a non-traditional way scored huge points with end users. Another carrier proved significant savings by building reusable services that ultimately led to the de-commissioning of three similar legacy systems.

Challenges remain, though. Movement towards Agile and other iterative development methodologies are gaining traction, but some people expressed frustration with resistance from key stakeholders. Change is often difficult, particularly with entrenched user groups resistant to new ideas.

Even so, I’m more convinced than ever that modern software development processes will soon become commonplace. Despite the challenges ahead, a clear shift is underway. Rapid development, reusability, and true SOA are all part of the direction. That makes me very optimistic about the future.

Rich Grisham