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

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.

A great software product shouldn’t have to encapsulate and limit their users just to keep them “hooked in”; the product itself should be useful and attractive enough for users to want to continue using the program. So what kinds of “capturing” tactics should you look out for, and what can you do to have greater control over the software solutions you choose to power your business?

1. Request to know what kinds of integration and compatibility options the system provides. – Software vendors often take an all-or-nothing approach that often limits integration with other software products and services. This lack of integration results in manual conversion of data between software that hinders the efficiency and capacity of your business.  The purchaser should be able to use non-competitive 3rd parties where applicable. If the system does not allow for integration and compatibility for the products you’re already using or hoping to use to power your business, evaluating whether that trade-off is worth it is a must.

2. Request for training, documentation, and configuration. - Oftentimes, software vendors will either develop a “black box” application without access to the code of the program, or give you a product so complicated that it requires a vendor expert. Without access to the inner workings of the software product, the customer is completely dependent on the vendor for how the system operates (and in turn, how your business is run).  By requesting training, configuration tutorials and system documentation, you can ensure you’re getting the most control over the product as you can.

3.  Request to know how the products work together and to access training materials on configuring them yourself. – Compatible software products from the same vendor provide additional software functionality to your system, but they can also leave the customer clueless as to how to use the products together if there is no knowledge or training transitioned between them. If you choose to use the original vendor across multiple products (which you may be forced to), it’s important to understand how you can use these compatibility options to get the most out of your business processing system.

4. Maintain as much direct contact with the vendor as possible, and make use of any feedback service the vendor offers. – Large, out-of-the-box software products from major software vendors rarely provide all of the functionality that you need to run your business exactly the way you want (despite the large price tag you dished out for a name brand product). Often times, the packaged system will come with plenty of bells and whistles, but falls short when it comes down to the real tools you need to build your business. Yet these large software vendors rarely allow the customers to direct the development of the products they buy, limiting the opportunities for feedback, compromise, and criticism of what they use (and put up with).  There are no guarantees that large-scale vendors will pay any heed to feedback, but it is the customer’s right to have an active voice wherever possible.

We believe that it is important to invest in human capital both in house and off shore. I’ve worked with many major outsourcing firms in India (as well as worked for one) and most have a “process over people” approach. Their main priorities are the hiring practices, training procedures, development process and rates (per hour/day) and not the quality of the individuals or throughput of expected output/deliverable. In my experience with these outsourcing firms, the ones that are the most successful are the ones where the people are treated like people. Point is — they are people too and when treated with incentives that reward their work and input, like anyone, they are far more productive.

How we got the most out of our off-shore teams:

1. Treat them like your own: By treating our off shore workers as if they were our on-site employees, they are enthusiastic about their contribution to our product and work more efficiently to meet our company goals. Some of the ways in which we have treated off-shore like our own are:

• Pay for company outings
•  Create a bonus pool to compensate them for their extra efforts

2. Invest in cultivating face to face relationships: By creating and investing in more personal relationships with the off-shore team, they not only feel a greater morale and loyalty towards the company, but will recognize themselves as a part of the big picture. Ways we’ve cultivated face-to-face relationships:

• Brought them to the US to work in our headquarters in Edison, NJ
• Sent our employees to India to work with the off shore team
• Invited them to company meetings and parties when they were here in the U.S.

3. Conducting quarterly reviews to make sure the company and individual targets are met ensures that both the company and the employee are growing and getting the most out of each other

4. Real-time communication as much as possible – skype, IM, video, calls, etc.

5. Retain the good people: I strongly believe that the range of production you get out of an average person vs. good person vs. great vs. elite triples at each level. So, the range of productivity from average to elite = up to 27 times greater (3x3x3). So, when I get the good, great and elite people on my projects, I don’t want to trade them in for average (or god forbid “below average”).

6. Make sure everyone sees the big picture. Sub-teams are always necessary to break down tasks and projects, but they have to feel part of the overall team and understand the big picture. By creating an environment where they feel like an integral part of achieving the company’s overall objective, off-shore developers will take greater responsibility for the quality and success of the product.

7. Let the senior people do the work: many cultures want to be in “management” and not do the development, design or testing – incent people to “do the work” at all levels, and everyone will work that much harder to produce something they can be proud of.

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.

“More with Less”

If you look at Celent’s CIO study from earlier this year, the major theme was: Business expects more from IT. They reference supporting expanding list of initiatives, prioritizing across business groups, escalation of expectations of IT, and balancing cost reduction/capability creation as key challenges and pressures they’re facing.

In the last downturn, companies settled for budget cuts equating to less productivity.  Now, I believe we’ll be challenged to get the same amount done for less budget. So, what can be done?

• Go Agile – if you’re already using an “Agile-like” development methodology, great.  Dive in and examine how you manage your priorities, who the impact players are, and which areas of the process are adding most value.  Eliminate everything else.
• Get the most out of the tools that are currently available – FAST 8x  (http://www.fasttechnology.com/software/8x/) is an example and I’d be remiss if I didn’t promote our own software.  With FAST 8x, you can build smaller components to solve targeted business problems at a fraction of the cost, time and risk.
• Avoid big mistakes – Diversify by spreading out your initiatives and deliver value sooner rather than later.  Don’t buy that big packaged core system that is going to be a burden on the entire organization, cost too much money, and risk the farm.
• Staff reduction is not a “cure all”.  Obviously, eliminating staff and consultants are necessary triggers that can be used to work within a budget cut, but that will most likely compound the problems with the business needing more.  In some cases, you might want to cut even deeper to free up cash for tools and the “right people” to help you navigate through these times.

Pressures and challenges could increase.  Are you prepared?

Tom Famularo

FAST

Whether you’re building a home or a system, the architecture is the first thing you decide upon.  It’s fundamental.  Just as the architecture for a home lays out the blue print for the physical structure, the architecture of a system lays out the blue print from which components and functionality are developed. Before the first batch of concrete is poured or the first line of code is written, you put that blue print in place, and from it every piece of the home or system is defined and developed.

With large-scale systems like policy administration, every line of code is written with that architecture in mind and it is core to everything in the system.  The architecture defines the very essence of the system – it is beyond “foundational”.  Once you go down an architectural path, you might be able to make changes to it, but there’s no re-doing the architecture unless you throw everything out and start from scratch.

So when vendors throw around the term “re-architect”, I think it can be very misleading.  “Re-architect” seems to imply that they have applied some fundamental, structural changes to the software without compromising the system itself; yet, to truly “re-architect” anything would mean a complete overhaul of the architecture that defines it. So, it’s kind of a misnomer.  If they had actually rewritten the system, they would say “we did a complete 100% rewrite from the ground up”.  If they didn’t rewrite it, then there is NO WAY the system is not compromised by the legacy architecture it had.  When you’re purchasing a system – large or small –, there’s a fair amount of legacy architecture and legacy code that comes with the package in almost every case.  You may be OK with that, but you need to have a good appreciation for the extent of it.

Along the lines of finding the “freshness date” or newness of the architecture of the system – as well as just doing some good due diligence – here are 20 key questions I think you need to be asking your vendor as part of the assessment:

1. When was the last time you “re-architected”?  What parts were not rewritten and why?
2. Why was the “re-architecting” deemed necessary? And what was the overall impact to the system in terms of % of code rewritten?
3. What year was the oldest code in your system written?  (I suggest you have the vendor make that a contractual representation and you should get an honest answer.)
4. For your policy administration system, do you have a monolithic or component based object structure within your code?  If component, do your components reference each other within the code?  Are there database joins that go across your components?
5. Can you tell me how many lines of code your software is (by language)?  (The purpose here is to gain an understanding of the ratio of newer code to legacy or older code.)
6. How many customers have converted or committed to converting to this new architecture? For those who have converted, what was the average project duration?
7. How many lines of code did you write for each of your last three new client implementations?  How long did those implementations take?  (Make sure you can reconcile the lines of code to the duration and that it passes the “smell” test – in other words “if there’s that little code, why did it take so long?”)
8. Assuming coding changes are required (and they will be), what restrictions are there on using external consultants?   Here the vendor will likely represent that you don’t need to make changes to the core system – do not under any circumstances accept that answer.
9. How many developers do you have supporting clients offshore and onshore on this platform today?  (Given the low amount of programming you will be told is required, make sure you can reconcile this answer to the answer in #7.)
10. Am I forced to use your proprietary rules engine?  How easy is it to swap out?
11. What contractual guarantees are you willing to make about maintaining this platform in the future and future releases?
12. What is the biggest implementation (# of policies) that anyone who is running on one of your past two releases of the platform we are buying?  (Work to make sure that the answer IS for the platform you are buying.)
13. List your current clients for the platform I am buying and version of the platform they are running.   (Accept that some clients can’t be named, but insist on a complete list.)  Exactly what functionality are they using and what is the product mix?
14. Can I have the attendee list from your last user group meeting?  This IS NOT highly confidential and they should be able to give it to you.
15. Who was the last policy admin customer to go into production for individual life?  Individual annuity?  What were the released version those companies used?
16. How long did it take your last policy admin customer to go into production (from initial requirements through production)?
17. Over the past five years, how many companies who have selected your platform where you started projects and the customer never ended up going into production?  (This is information you can learn for yourself in the industry.)
18. How many policy administration customers do you have that haven’t made a significant number of code changes for customization?  Please name them.
19. How many policy administration customers have done production upgrades to a newer version over the past five years?
20. How many customers have terminated maintenance agreement in the past three years?

Now, my son runs high school cross country and 5 ½ minute miles for a 5k (3.11 miles) is pretty much where you need to be to be competitive.  Benchmarks are set and each year new freshmen come in and shave minutes off their times to meet the established standards.

Basically, how good is “good” is a matter of perspective and benchmarks.  Measuring speed, of course, is very easy and very objective.  There are teammates and years and years of records to compare to, so it’s easy to say what good is.

With software development, we really don’t have a great way of measuring “good” productivity.  Sure, we can measure quality and ability to meet commitments, but how do we know the productivity was good?  And how do you incent people to be good?

How can we tell the difference between the developer who runs the 10 minute miles (and he looks good doing it) and the guy who runs the 5 minute miles?  How do we reward them?

Do you ever feel like your developers are walking at a 20 minute mile pace and passing it off as “running”?

John Gorman

FAST

In several other studies I’ve read, the number one motivator was recognition for a job well done.  I’m still a believer that if you make a lot of progress, you’ll receive the recognition for a job well done.  So, personally, I like to focus on things that can help me make a lot of progress that can be seen on a daily basis.

The other factor I’ve heard from IT professionals over the years is that they want to work on new and interesting things so they can be challenged, learn more, and make them more well-rounded.

Personally, the thing that is universally important to everyone is time.  We all have a limited amount of time in our lives – whether it’s enough time to get our jobs done, spend with our families, relaxing, or doing things we like to do.

One Size Doesn’t Fit All

Overall, it sounds like a simple question – “what motivates IT professionals?”  While there are common desired objectives for different roles within IT, individual motivation factors often differ and are sometimes inconsistent with corporate objectives.  Quite often compensation incentives, perspective, and responsibilities drive different factors in achieving objectives for IT professionals.

Since so many stakeholders are involved with selection of software and/or development partners, this makes it challenging for IT providers to create offerings that are a “win/win” – because they often really need to be “win/win/win/win/win…”

FAST 8x Provides Something for Everyone

At FAST, we set out to help companies deal with legacy problems and expand their business capabilities while getting themselves into the right technical architecture in a cost effective, more predictable manner.  This is great for the bottom line and future of the company; however, we also want our involvement to benefit all of the individual stakeholders.  We want to create that “win/win/win/win/win…”

FAST 8x is our high performance software development automation engine.  It helps clients build individual components which can be deployed as standalone applications or as part of business process SOA architecture.
This platform brings something to the table for everyone.  In addition to helping companies, the unique capabilities of FAST 8x better allow individuals to meet their personal and professional goals. Let’s take a look a few roles within a company to see how they could potentially benefit:

I believe that projects and organizations can be most successful when everyone’s objectives are in alignment.  I think creating an environment where people can be highly productive will help them feel more productive, focus on more interesting work, get the recognition they deserve, and give them more of one of the most valuable commodities – time.

Tom Famularo

FAST

Life insurance software is complicated. The uninitiated or inexperienced might look at the way the life industry implements core systems and say “You’re making this overly complicated.” There is some truth to that usually, but the fundamental issue is that over complication is a “given” for the life and annuity industry.

So, we have an industry with complicated business models. We have systems and processes that have grown over time to support all kinds of exceptions and quirky products. Sometimes things are documented, sometimes they aren’t. Sometimes exceptions and products are handled “by the book” and sometimes they aren’t.

Unfortunately, it can be difficult to distinguish between:

• Necessary Complexity – to comply with regulations or to support a legacy policy as part of a conversion. This is a big part of the complexity.
• System-Imposed Complexity – some process was implemented because of a system constraint, but now it’s treated like a “must have” way of doing business. (This is usually unnecessary complexity.)
• Other Unnecessary Complexity – processes that have evolved and mushroomed unchecked over time; easy system enhancements that were never implemented; “leaky” manual processes that are error prone or overly laborious; etc.

Because of this, you need to find people who:

• Know the industry inside and out, so they know necessary complexity when they see it
• Are objective enough to challenge conventional wisdom and identify unnecessary complexity
• Are wise enough and knowledgeable enough to quickly and continually make these decisions

Basically, you need deeply experienced people who can think outside the box. And they’ll need to be in key positions for both the vendor and the client. What would I consider “deeply experienced”? A minimum of 15 years…

• Implementing core systems…
• Successfully…
• As a KEY CONTRIBUTOR
• For multiple insurance companies

There aren’t a lot of them us out there, but if you don’t have them on your project it will probably fail. You can take that to the bank (and you might be spending a lot of time there).