Posts Tagged ‘Innovation’

Three Lessons I Learned From Steve Jobs

Thursday, October 6th, 2011

To say that Steve Jobs was an inspiration to the technology industry is an understatement. When looking back on his career and the legacy he left behind, I can recall three important lessons that I have learned from Steve Jobs:

1.       Perseverance – Perseverance is by far, the most important lesson that I have learned from Steve Jobs. Jobs overcame many challenges in his lifetime and he persevered through every failure he faced. From dropping out of college to being fired from his own company to releasing products that failed miserably, Jobs never let his failures define his future. He challenged himself to think creatively and move on to the next opportunity.

“Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.” – Steve Jobs

2.       Innovation – What made Jobs brilliant was his innovative and intuitive thinking. Jobs thought of ideas before the consumers realized that there was a need for them. His innovation and creative thinking was the key factor in driving the market to where it is now.

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” – Steve Jobs, BusinessWeek interview, May 1998

3.       Simplicity – When I think of Apple products, the first thing that comes to mind are the clean lines and the simple, easy to use devices. Jobs used the same approach when selling the products.  Instead of describing the powerful technology in each device, he focused on the ease of use and simplicity of the interface.

 “That’s been one of my mantras — focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” – Steve Jobs

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 www.fasttechnology.com.

Tom Famularo
FAST

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 www.fasttechnology.com.

Tom Famularo
FAST

Why Most Successful Companies Stop Innovating and 8 Ways to Avoid the Trap

Wednesday, April 21st, 2010

“Learning and innovation go hand in hand.  The arrogance of success is to think that what you did yesterday will be sufficient for tomorrow.” William Pollard   

Most companies start out with innovative ideas around products, services, or even processes to solving problems.  Successful companies will get to that next level as a result of their implementing those innovative ideas.  Then, why do so many companies stop innovating?

Why do companies allow themselves to be a one-trick pony?

When companies are small, nimble and hungry with “nothing to lose”, they are able to come up with innovative product ideas and implement them quickly and cost effectively.  A company will spend years expanding, perfecting and selling its products.  The management will be passionate and love their products and the products define the company.  For a company to be successful, there will be a solid customer base that is happy with the product, and the company may experience significant growth based on the product.  All of this sounds good, but it can be the beginning of a trap that stifles innovation.    Here are some of the reasons companies can fall into that trap:

  • Management becomes too emotionally attached to their creation and doesn’t recognize when technologies have changed and it’s time to start over.
  • When growing the company, management often puts processes in place, geared towards “the masses”.  As such, risk taking stops being rewarded and the culture becomes more about delivering consistently rather than finding breakthroughs. 
  • The talent pool becomes significantly diluted – because the best people need to be reserved for managing the masses and “growing in their careers”. 
  • The exposure the bulk of the employees have is to their customers under the context of this product and the customer is primarily concerned with incremental enhancements for their narrow focus

As a result of this, the costs are too high and the motivation is too low.  The diluted talent pool following stringent processes drives the cost up to multiples of what things should cost and without the push from management or customer’s, it’s difficult to justify the investment.

The really successful companies end up getting acquired by a larger company who has recognized that they were unable to build something similarly innovative themselves.  Unfortunately, most acquirers “know better” and enforce “big company processes” that stifle any hope of providing innovative solutions to the problems.

8 Ways to Avoid the Trap

  1. Sounds like a cliché, but it’s true:  Recognize the problem.  Understand how you got to where you are and harness that.
  2. Allow research and development to be done in smaller groups of talented people.   Those small groups can be compartmentalized within the company or even independent of the company (partnering with other entrepreneurs).  You can even use social networking developer sites like guru.com  or topcoder.com to do proof-of-concept work. 
  3. Allow those smaller groups to work “outside the processes” in a skunk works modeRemember when you first started, it wasn’t required to write a 30 page document before you wrote a single line of code.
  4. Reward innovation – have a culture where people can share their ideas and incentives are provided to those with the groundbreaking ideas.  The career path for a great innovator and/or implementer of innovation is not necessarily management. 
  5. Every interaction with a client, prospect, or the market is an opportunity to come up new ideas on how to innovate.  Whether it’s improving what you already have or something brand new, the questions asked by others should drive those creative juices.   Have an internal forum where people are inspired to capture this information while doing their daily jobs.
  6. Try stuff – don’t be afraid to try different things to see what will stick.  If you’re following #2 and #3, you can afford to build prototypes and prove out some ideas.  Recognize that 50% of what gets started may never see the light of day. 
  7. Make it a priority to get involved with your customers at a different level than just your product.  Ideally, you want to have a good relationship with the executives so they’ll allow you access to the people on the ground (both using your products and not using your products). 
  8. Avoid building “big stuff”.  By building smaller components that are meant to be replaced and/or evolved, you can avoid it being cost prohibitive to upgrade and/or replace.  As important, it reduces the emotional attachment of the original “authors” who are usually in a power position.

Even large companies can innovate if they institute some of these practices that were mentioned.   Unfortunately, there is usually too much red tape and they may be better off partnering with a small company or a start-up to achieve the level of innovation they need.

“If you can dream it, you can do it” – Walt Disney