Enterprise Architecture: From Incite comes Insight...

Carriers have lots of rules that govern everything from rating and underwriting to policy processing. Most carriers attempting to replace their policy administration system forget about this important point and discover too late that the number of rules will more than like overwhelm a new core system.

Smart insurers focus first on product configuration and rating migrating legacy systems to bespoke rating engines. Carriers often have multiple rating engines tied to policy administration systems, web portals and other systems which leads to inconsistent pricing, compliance issues and the inability to develop innovative products.

Many industry analysts fail to tell their customers that the rating engines that are locked into most policy administration systems are often inflexible and lack the ability to scale. Some carriers have even figured out that they don't really need to replace their administration system and just needed to focus on externalizing their rating and rules...

In your career travels, you may have ran across those IT leaders who always seek middle ground. The glow about achieving a hybrid approach. While this approach is popular, this often results in both suboptimal leadership and business outcomes...


Ever heard the phrase: Shit or get off the pot? What happens when you seek to choose a hybrid position? Are you OK with half of it being in the pot while the other half runs down your leg? Leadership isn't about appeasing people but more about achieving necessary outcomes when tend to be towards one side over another.

People love to be reasonable.Striking a balance makes the person who is attempting to strike it appear a reasonable sort of person. Who wants to be unbalanced? After you have looked at the pros and cons and understood the competing arguments, you should balance them out, yes?  But when someone strikes a balance, they rarely say what balance has to be struck and why. Instead, they throw this phrase in as the final justification.

It allows someone to come into a discussion and own new midway territory that is hard to argue with. Talk of balance can be reassuring when actually, what is needed is a radical rebalancing of priorities. No balancing is required when the scales come down firmly on one side. In short, striking a balance is woolly and platitudinous, neither ideal when you are dealing with a statistical reality. Fewer targets, just like a little bit of ham for a vegetarian or the Pope agreeing to share the Vatican with the devil, is still the wrong thing to do...

It is common for modern computer documentation to be filled with screenshots, demonstrating how to use every field and control of every window provided by an application.  This leads to thick documents with little long term useful information...



There is a significant cost related to keeping documents in sync with the software they describe. If the documentation is being developed at the same time that the software is being developed, it is possible that screen layouts will be changed at the last minute, requiring last-minute changes to the documentation. When a new version of the application becomes available, a whole new set of screenshots must be generated and inserted into the document. This leads developers to avoid improving screen layouts or adding valuable features due to the cost of updating the documentation.

In many enterprises, there are review processes for pretty much everything that gets created, including documentation. Whenever we go down the path of focusing on screenshots, we get drawn into a trap of then also worrying about whether we are using the right icons or other aesthetic considerations while ignoring substance.



Does someone truly benefit over the long haul in having documentation that shows a First Name field should be populated with a first name? I have observed that if user interfaces require documentation then it tends to point to a lack of focus on usability while developing the application. What if we decided to do the exact opposite and find ways to make documentation history?

Should screens for enterprise applications be self-documenting? Many screens tend to mirror the needs of the data to be captured vs focusing on what is the outcome the user wants to accomplish. Think for a moment about your most favored enterprise time tracking application. Does having a box of rows and columns where the user has no freakin clue as to what to put where feel like a request for documenting screenshots or does it feel more like an opportunity to do things differently?

An outcome focused timetracking application would have a totally different interaction. Consider the scenario where a team of people are assigned to a long-term project and for the most part do the same activities on a weekly basis. Imagine a timetracking application that upon signin knew who you were and started with a simple question of: Did you do the same activities this week as last? and simply copied them using whatever logic is appropriate...