all bits considered data to information to knowledge


New Meaning of “Investing in Your Health”: an idea for Health Insurance Exchange

As states race to implement Health Insurance Exchanges mandated under Affordable Care Act, I wonder whether they have chosen a wrong model - that of an overseer, an information provider and a mediator... Maybe we could have borrowed a paradigm from Stock Exchange market?
Some of the major hurdles facing Health Insurance Exchange implementation include
  • inherent complexity of the endeavor
  • insufficient experience on the state part in operating exchanges (as opposed to financial industry)
  • need to attract sufficient number of participants to become efficient and self-sustaining
It is a common pattern in software engineering to deal with complexity by introducing an abstraction layer,
and financial industry did just that with the concept of Exchange-Traded Funds and Mutual Funds to ease complexity of picking individual stocks. I believe that Health Insurance Exchange might have much more in common with exchange than insurance, and that the very same concepts are applicable here.
Imagine health insurance pools structured in a way similar to that of mutual funds/ETF according to some predefined criteria, and designed to cater to a certain category of consumer (again, analogy of industry sector funds). It is then sold as units of insurance to consumer through the exchange.
The role of the Exchange operators would be that of mutual fund managers:
  • design portfolios of insurance plans and sell units of insurance to consumer (after proper validation and categorization)
  • handle fund-to-fund exchange (when situation of the customer changes)
  • process refunds and assess charges
  • provide apples-to-apples comparison
  • etc.
The insurer and the insured will be decoupled: the former will roll out insurance plans, and the latter will buy as much insurance or as little as they need, and the State's Health Insurance Exchange would provide platforms for "health insurance pool" comparison and rating, and handle financial transfers (including state/fed subsidy portions)..
In a commercial twist to the idea: since the funds have an expiration date, the insurers might even pay dividends to the units holders based upon un-used portion of the plan (insert actuarial voodoo here :).
There might be even a secondary market where investors might buy funds from customers (original units buyers) if they can reasonably expect positive return due to under-utilization of the plan.

Evolutionary Best Practices

“Best practices” are the proverbial wheel. You know - the one that does not need to be re-invented… The Wikipedia article defines best practice as “ a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark.” It has been recognized as “management practice” and even made into ISO 9000 and ISO 14001 standards.

Yet they do have a shelf life, and stale “best practices” is nobody’s idea of efficiency. The very same Wikipedia article adds that 'a "best" practice can evolve to become better as improvements are discovered.'

An evolutionary metaphor seems to be apt for a definition of “best practices” - in order for the species to adapt to changing environments they must evolve, in order for species to be recognized as such they must preserve their distinct genetic makeup for some reasonably prolonged period of time.

The trick, as usual, is to recognize the right time to embrace the change, or to reject is. In natural evolution, as in the business environment, the right turn at the wrong moment is just as deadly as wrong turn at the right moment - both would result in particular species (uhm… businesses) being sent to the fossil beds.


Who mines the miners?

Organizations like to keep their cards close to the chest.  For a long time BI/analytics was all in-house affair: tools, skills and - especially! - data. The shift towards distributed computing models such SaaS and PaaS change everything.

The data needed for analysis might not be owned by the company; it might live - virtually - anywhere: public domain, subscription service, social networks such as Facebook, geographical data from Google Maps or Microsoft Earth. This is the secret ingredient for the analysis, and just as every true secret it hides in plain sight.

SAP has announced that its flagship analytics BI - Business Objects 4.1 - will have even tighter integration with Google Maps API, going beyond location services…

One can’t help but wonder  what data Google gets to keep for its own analytic endeavors as it tracks each call to its services.  Could it be that the corporate secrets are leaking out through usage patterns?


Who needs a Software Factory?

Software [Development] Factory – a concept most eloquently formulated by Jack Greenfield – did not generate much following. The first book Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools authored by Jack Greenfield (also, see MSDN article), Keith Short, Steve Cook, and Stuart Kent was published in 2004, followed by Practical Software Factories in .Net in 2006, with but a single title advertized for release in 2010 (Agile Software Factories by Damon Wilder Carr)

Apparently it did not struck a chord with majority of software architects and developers out there. Some of the reasons could be developers resistance to commercializing and commoditizing the high art of software development; some of it, I believe, could be attributed to misunderstanding of the applicability domain. Simply put, techies do not need it, and business folks do not understand it.

The promise of SDF is to deliver “economy of scope” where “assembly lines” produce variations of archetypal product/template, it is therefore inherently not applicable to one-off projects. I see the SDF closely aligned with Software Product Lines (e.g. Software Product Lines: Practices and Patterns ), where business domain knowledge meets “patterns, models, frameworks, and tools”.

 There could be no discussion about value of patterns, models, frameworks, and tools; these are given for any software project worth the name. They are firmly established in software development practice. Move up one notch in the abstraction ladder and you have all these wrapped up into archetypal template from which you can generate a variation of a domain specific product. An example of such “wrap up” could be used through a DSL  - Domain Specific Language used by business domain experts. Say, you  - a domain expert - are assembling a financial application that processes loan applications – would not it make sense to use language that finance people could understand with keywords such as “loan”, “mortgage”, “originate”, “fee” etc.? Just as most developers shudder at learning intricacies of APY (Annual Percentage Yield) versus APR (Annual Percentage Rate), the finance folks would not want to be caught dead talking about threads, mutexes, arrays and data types... SDF paradigm allows for both to coexist peacefully: technology aficionados take care of the underlying machinery, and business can assemble applications they need without need to translate the requirements - times and again – into techspeak.

 Now, how is it different from CASE  promises?  Here’s my answer: SOA+DSL. The SDF transcends CASE in a way of operating at ever-increasing level of abstraction, where models do not have to be translated into software modules but rather into software services wired together to produce desired functionality, where patterns are built into the language the domain experts use (think BPEL+), where software engineering best practices are implemented on subconscious level…

I can see these trends when IT folks are increasingly urged to “speak business”, when mash-ups and Google Gears allow for creating a reasonably functional web application with minimal understanding of what technology all these gadgets are using, with proliferation of ECM – Enterprise Content Management systems such as Drupal, Alfresco, Sharepoint, with DSL taking more prominent role (check out Microsoft's Domain-Specific Language Tools for .Net)