Dave Moran's Software Development Blog

Code & Ship: The Final Chapter

Sat, 19 Jul 2008 13:11:00 GMT

Closing blog on the "Code & Ship" series covering the software development process at AMS Services in Portland, Maine.

What is a Software Developer? Part Two

Mon, 07 Jul 2008 01:10:00 GMT

What goes into the actual construction of software?

What is a Software Developer? Part One

Sun, 22 Jun 2008 22:07:00 GMT

What goes into the actual construction of software?

Why Aren't Developers Coding?

Sat, 07 Jun 2008 19:33:00 GMT

The project is staffed, the requirements are understood. Can we start coding?

How Do Software Teams Meet the Customers’ Needs?

Mon, 26 May 2008 12:39:00 GMT

How do software teams that don't know the insurance industry intimately develop an understanding of what needs to be built?

Software Development: More Than Code and Ship

Sat, 10 May 2008 11:39:00 GMT

Write some code, package it up and ship it... Software sounds easy, but is it?

Business Users and Developers: An Impedance Mismatch?

Sun, 27 Apr 2008 17:51:00 GMT

Why do business users get frustrated with developers?

It's an Interconnected World...

Wed, 09 Apr 2008 11:28:00 GMT

I have a BlackBerry that is always attached to my hip, in and out of the office. Why? Because even while I’m grabbing yet another cup of coffee (that I don’t really need), my BlackBerry gives me immediate access to e-mail and appointments. Have you ever been in the middle of a spontaneous conversation and felt that you really should go back to your desk to check your calendar to ensure that you’re not missing a meeting or appointment? Having a BlackBerry in hand spares you this dilemma, (aside from the fact that you may put someone off by checking your calendar while you are in the middle of a conversation!) but it is more than just an inter-office convenience tool.

I classify my BlackBerry as a personal productivity tool, and it is certainly proving to be well worth the investment. No matter where I am, including those semi-annual trips to the dentist, I can always quickly and easily check e-mail and respond if need be. While it can be argued that being too connected is not a good thing, it is the convenience and efficiency that has won me over. There are times when even a laptop is too much to be carrying around, but a BlackBerry is no trouble at all – and it is quick and easy to check your messages.

In reality, the connectivity alone does not justify the monthly rate that I pay for my BlackBerry. It is the compelling benefit derived from the connectivity is what makes the investment worthwhile to me; Research In Motion (the makers of the BlackBerry) have created a device that is very usable – I must confess that I wondered how I would like typing messages on such a small keyboard, but once you get the hang of it, it isn’t that bad. Research In Motion has created a device with a specific focus that is very usable.

This is the reason that we’re keen on partnering with you as we evolve our products to meet the needs of an increasingly interconnected world. In the insurance space, there is a great deal of processing being performed in various dimensions, including policy, billing, claims, and reporting. The major question of the day is: What needs to be exposed in an interconnected world, and what can remain the same?

This is where dialog and feedback with you – our customers – is vitally important. As we move forward with exposing key processing on the Web, we will be considering more than mere connection points alone. We’re making the investment to provide you with the benefits of open, readily-available connectivity. In order to do this, we need to be connected with you.

We’d like to partner with you to solve these problems for our mutual benefit: It will help you provide benefit to your customers, and it will help us shape our software to meet your new demands and needs. We also understand that today’s world involves you with much more than just Phoenix, and we’ve have the knowledge and skills to help you meet those challenges.

While we have not always been great at tooting our own horn, here’s a quick resume: We’ve designed and built PremiumBill; we’ve designed and built Automated Out-Of-Sequence processing leveraging Phoenix Web Services; we’ve designed and built custom reporting tools; we’ve designed and built real-time, web-based access to Phoenix (ART) rating; we’ve designed and built interfaces to third-party services like ISO…

In short, we have a talented, knowledgeable group of business and development expertise on staff capable of helping you move forward in all of your initiatives. We have over a decade and a half of experience in designing, building, maintaining, and modernizing enterprise-level software, keeping abreast of the latest tools and trends, and we would be delighted to partner with you to apply what we have learned.

I encourage you to participate in the forums that we have on this web site, and to check out the blogs and articles that we are posting on a regular basis. And by all means, talk to us about your connectivity needs and challenges. We have people who are dedicated to sales, support, and product development at the following link:

http://amscarriercommunity.com/phoenix/ContactUs/tabid/137/Default.aspx

Why Agile?

Mon, 17 Mar 2008 11:45:00 GMT

Joe Sanderson’s How much per pound? blog provided excellent inspiration for the topic of this blog. Joe relates how you will benefit by collaborating with us using an agile development methodology. This involves working with us to create user stories that articulate your requirements, in business terms, to ensure that the software we deliver is what you need and expect – something that can be more difficult to accomplish that it might seem!

When it comes down to it, insurance software deals with complex business transactions that involve large amounts of data. This alone is a challenge. From out standpoint, we want to keep our solutions configurable, providing you with the advantage of adaptability without having to ask us to re-work our software to meet changing business needs. Now combine this with the fact the while every insurance company feels that they process information in a “standard” way, every company varies in how they actually process business. As configurable as Phoenix is, we’ve never made a sale in a decade and a half without some modification that was considered essential.

In general, software projects that are deemed failures typically can trace issues back to developers either not understanding the requirements (and building something that the users don’t want) or a project team taking on too much at one time – all in the name of creating a “feature rich” application – with significant cost overruns and buggy code because there is too much added, far too quickly. Imagine working on a project where those writing and testing the software did not have a clear idea of what needed to be built, “everything” is a priority, and there are literally dozens of features to be developed. What do you think the odds of success would be? In the software world, this scenario is played out far too often.

One response to this is to use a rigorous “identify and document everything up front” model, known as the waterfall model. This model requires that one phase cannot start until the previous phase is complete. Requirements must be documented first, then estimates provided so that a full project plan can be created, and then – finally – design, coding and testing can begin. Any changes to the initial requirements and plan are put through an equally rigorous “change control” process.

This sounds rationale, and equates software architecture and design with building a house or office building. The problem is that this analogy is by no means accurate. Unlike building construction, developers are building on top of an ever-changing technical foundation, with ever-changing development tools, all aimed at addressing increasingly complex business issues.

Another harsh reality is that business users cannot always express exactly what they want and how they want it, all up front. It’s far easier to visualize a house or building from a blueprint because we see them every day. Solving new business problems in new ways, typically tailored towards business workflows and preferences, is far more difficult to visualize and agree upon up front.

Given all of this, I’m sure that you can appreciate that it is extremely difficult to pin down how long it will take to build out a specific feature, let alone meet an entire project plan! For developers and testers, it is even more difficult to precisely estimate given that the full business understanding is in someone else’s head.

How does agile address these issues? Agile development is all about inserting those who understands the true business need with the project team charged with delivering the software in a meaningful, participative way. In Joe’s example Susan, the business analyst is assigned to an agile development team to deliver a solution. As part of an agile team, Susan not only will help the team understand what needs to be built, but she will actively be involved with prioritizing the work as well. Prioritization another key tenet of agile development: by focusing on the highest-priority items first, agile development ensures that those items considered to provide the most benefit are delivered as early as possible, with quality.

Agile focuses on delivering working, testable software in very short iterations. This provides some meaningful benefits. In the first place, working software is delivered, providing a solid measure of real progress. Since a stakeholder can see the actual software, changes can be requested for subsequent iterations – agile development acknowledges and embraces this level of interaction. A final benefit is that as a stakeholder, you can decide that at a given iteration the software has delivered enough prioritized features to meet your needs and you can elect not to have the team build out the other, lower-priority features.

More on agile in future blogs…

Service-Oriented Architecture and Phoenix

Sun, 10 Feb 2008 12:27:00 GMT

Since I asked readers about the types of processing deemed essential for us to expose via Web Services, the thought occurs to me that it would be a good thing to discuss Web Services and the importance of Service-Oriented Architecture (SOA).

Service-Oriented Architecture covers a lot of ground, so I’ll delve into that first. In general terms, software architecture concerns itself with the design and structure of a software system. Software systems are compartmentalized into layers, subsystems, and components (and objects, methods, and so on). Software architecture defines these entities and the communication interfaces that will be used for all of the parts to converse with one another.

Service-Oriented Architecture focuses on business-level processing. Software is still constructed in a layered, modular fashion, but with each software service providing a defined, related set of business functions and capable of operating as an independent entity. Our PremiumBill product is an example of this. It has one job (service): insurance billing. It operates as an independent entity with its own business logic and database, a design that in turn allows PremiumBill to support Phoenix as well as any other policy processing system.

The communication interfaces of SOA-compliant systems are likewise focused on business processing. XML and Web Services (covered in a moment) are commonly used to implement these interfaces, resulting in a significant benefit: one application doesn't have to know the technical details of another application in order to communicate with it. This eliminates the embedding of inter-application calls in the applications themselves, something that becomes a maintenance headache over time as well as making it significantly more difficult to replace applications down the road.

The final step with Service-Oriented Architecture is to tie the various (business) services together to provide a complete, end-to-end business solution. To sum it all up in one sentence: Service-Oriented Architecture is also about modeling the enterprise as a collection of services, with these services geared towards business functions.

Since I mentioned Web Services and XML I’ll close the loop on those here. Web Services are used to implement business-level communication interfaces in an SOA world. They are the mechanism that allows applications to communicate regardless of the language they were written in or the platform that they execute on. Windows and Linux-based applications – whether they are written in .NET or Java – can communicate and interoperate through the magic of Web Services.

XML is also an important piece of the puzzle. As we continually expose Phoenix processing via Web Services, we’ve been making use of XML quite heavily. XML – or Extensible Markup Language – is an open standard used for structuring and sharing of data with applications or services. An XML document contains both data and descriptions about the data, making XML “self-describing.” XML is also extensible – meaning new data elements can be defined.

We’re generating XML definitions (called schemas) as part of our Phoenix XML Web Services. These are based on policy configurations within Phoenix, and are designed so that we can work with and use policy data provided in an XML document. When you call a Web Service to rate a policy, you hand that interface an XML document that contains the policy data (in reality, a program will do this on your behalf), and a rate is returned by the software service updating the XML document.

As you can see, we’re sold on SOA here at AMS Carrier Services, and we see numerous advantages to SOA for our customers. Some immediate thoughts that come to mind: a) The fact that business-level interfaces are exposed opens the door to workflow automation; b) Applications can be more readily maintained and improved; c) New software can be introduced far easier.

It’s easy to see how all of this relates to newly-designed systems like PremiumBill. But how does all of this relate to a legacy system like Phoenix? Based on understanding what SOA, XML, and Web Services are, and the fact that Phoenix was not designed to operate in this universe, I hope that you can see that we’re in difficult, but not unmanageable waters.

We’re building out interfaces into the product, using SOA design principles and leveraging the technologies of XML, Web Services, and .NET languages. We’re essentially building new business processing logic that accesses key Phoenix capabilities – like ART rating – and interacts with the Phoenix database. In essence, we’re leveraging and protecting our mutual investment.

This provides you the best of both worlds. Your existing business processing can continue, and we can meet new needs through exposing the necessary business processing via XML and Web Services. In order for us to do this, however, we will need to re-architect and re-write portions of our product.

This is where you come in. It is an expensive proposition to completely re-write Phoenix, and it is not something that can be done all at once. We want to focus on the areas you need us to focus on. I’ll close this blog with the same questions I asked in the last blog: What are your key challenges with Phoenix? What processing do you deem essential for us to expose via Web Services?

Some Web Services seems like a slam-dunk to us: Inquiry capability for policy, billing, and claims, and First Notice of Loss. Others that involve change processing open up a much broader spectrum of processing. What type of change processing do you really need exposed via the Web? Since we can’t build everything overnight, what would be the priority?

I look forward to your input and discussions on this topic.