Are Insurance Carriers adopting the worst practices of Banks?

We all know what happened to the banking sector and its cataclysmic collapse. Some people think banking collapsed do to its incestuous greed and irresponsibility in making horrific underwriting decisions. While these are contributing factors, I believe that the issue at hand is in putting profits ahead of people...



Its now 2012, the year of the empowered consumer. We can no longer expect consumers to exhibit brand loyalty when it has become apparent that they are no longer respected as individuals. Marketers everyone are attempting to classify, categorize and taxonomize consumers into nice little buckets while ignoring what makes them so valuable.

Empowered customers will figure out that insurers determined sometime ago that it was cheaper to use price and sales to win/retain their business than it was to earn their custom and loyalty through value and service. It is the insurance industry version of the same flawed "high leverage/high growth model" strategy that the banks blew-up!

This inward-looking and self-serving approach focused upon improving margins for the operator at the expense of the customer, rather than on the type of "creative destruction" to improve products/service and has ultimately left the industry reputationally damaged and untrusted.

As we continue down this destructive path, I humbly predict that the rise of technologies ranging from business intelligence to channel transparency will further erode the value proposition of insurance to consumers. With passion, I humbly predict that this will be a year where the increase in loss ratios will outrun the ability to increase prices. Anyone care to argue differently, I welcome their insight...

Did you lose your fancy job title?

During the Christmas holidays, I met up with a few friends who shared with me a story of several individuals I know who recently lost their fancy job titles. There are always multiple right perspectives...



How many architects does it take to change a lightbulb? The answer remains unknowable. What we do know is that many job descriptions suffer from title inflation. There are UI architects, Java architects, enterprise architects and so on. Sadly, many of this people have used the word architect in their job title to indicate seniority vs. ability.

As an Enterprise Architect myself, I am a student of simplification and a champion of rationalization. In short, I believe that too many people have the title of Architect and that we need initiatives to bring about industry-wide title rationalization. Simplification of job titles is one step that should be considered by Enterprise Architecture teams as a way of making IT appear less complex to the business. In doing so, the business has a better chance of understanding whom to approach with game changing ideas vs getting caught up in the quagmire of the plethora of titles.

While it is noble to do the right thing for the business, we also have to consider the impact of titles on the people who hold them. Usually, job grades are embedded in titles, and promotions make the new job grade public through a new title. A person’s job grade is generally considered public information. If employees are fairly placed in their job grades and promoted only when they are clearly performing at a new job grade, then salary differences based on job grade are generally perceived to be fair.

The negatives of title simplification tend to add confusion to the marketplace in that the range within a title now happens to be much broader. More importantly, removing titles from the toolbox of tools now means that the focus will need to shift to alternative rewards. Gone are the days where you could get away with giving an adequate pay raise with a snazzy new title.

For employers that are looking to make things simpler, I hope they will take the prudent course of action and acknowledge that titles are bi-directional entities that provide value for all involved parties.

Liferay Portal: Thoughts on ServiceBuilder

There are a few opportunities for improvement in the functionality of ServiceBuilder. Below are my thoughts...



1. Liferay does a good job in making itself manageable, but could take a further step in leveraging JMX to create additional visibility. Generally speaking, when you create a custom service, you may want to expose metrics such as uptime, number of invocations, etc. It should be relatively straightforward for ServiceBuilder to also create a JMX MBean that provides visibility into service operations.

Whenever a service is started, it could automatically register itself with the MBeanServer. Alternatively, you may want your MBeans to be available as soon as you deploy your application, listen for notifications from the deployment service.

2. Many enterprises want to increase the testability of applications they put into production and will naturally gravitate towards tools such as JUnit. Since Liferay creates services that can be exposed via SOAP and JSON, there is an equal opportunity to automate the creation of unit tests for these invocation methods. The ability to test JSON APIs may be best accomplished by using the JUnit extension known as HTTPUnit.

3. Liferay needs a better way to handle subtypes. A supertype/subtype design requires that some attributes be stored in the supertype, and some be stored in the subtype. The attributes for each thing in the real world are split between two tables/entities. This may be useful in a variety of scenarios where you need to store different typed attributes for a given population.

One example that comes to mind is for storing information about different types of users. Imagine a role-based portal where you have agents, employees and consumers all using the same resource. An agent may have a unique industry-provided identifier such as a professional license. An employee may have an employee ID and so on. A service that understands these relationships would be very powerful...

What exactly is a consultant?

Below are a few questions that will help you delineate consulting from other professions:

* You work very odd hours.
* You are paid a lot of money to keep your client happy.
* You are paid well but your pimp gets most of the money.
* You spend a majority of your time in a hotel room.
* You charge by the hour but your time can be extended for the right price.
* You are not proud of what you do.
* Creating fantasies for your clients is rewarded.
* It's difficult to have a family.
* You have no job satisfaction.
* If a client beats you up, you get sent to another client.
* You are embarrassed to tell people what you do for a living (people ask you what you do and you can't explain it)
* Your family hardly recognizes you at reunions (at least the reunions you attend).
* Your friends have distanced themselves from you and you're left hanging with only other professionals.
* Your client pays for your hotel room plus your hourly rate.
* Your client always wants to know how much you charge and what they get for the money.
* When you leave to go see a client, you look great, but return looking like hell (compare your appearance on Monday A.M. to Friday P.M.).
* You are rated on your performance in an excruciating ordeal.
* Even though you get paid the big bucks, it's the client who walks away smiling.
* The client always thinks your cut of your billing rate is higher than it actually is, and in turn, expects miracles from you.
* Everyday you wake up and tell yourself you're not going to be doing this stuff for the rest of your life.

Can anyone guess what profession I am describing?

Enterprise Architecture: Ways to make healthcare more affordable (Part Two)

I previously blogged on ways to make healthcare more affordable without compromising quality or availability. Today, I will share a few thoughts on what employers can do to bring down costs for their employees...



Reduce stress in the workplace: How come HR seems to only focus on employee benefits and not the cause of stress in general? We all know that stress causes cortisone to increase in the body which can impact those with high blood pressure, diabetes and even high cholesterol.

In an informal survey of Enterprise Architects that work for The Hartford, over 60% take some form of medication in the above three categories. Do you think there may be some correlation of the impact of healthcare to the leaders in which they report?

Another informal survey indicated that project managers were having an increase in diabetes. Who else thinks there is a high probability that this could be correlated to the fact that the culture has morphed away from people eating healthy foods in the cafeteria and doing group walks during lunch to one where people grab the quickest thing possible from the vending machine and run to their next meeting?

Provide healthcare at work: How many people have to take time off from work simply to make a doctor's visit? Many people have to take on stress of juggling their calendars just to get an appointment with a doctor for their stress! Why can't we save doctors for major medical concerns and instead provide a nurse onsite for minor ailments?

Even if you work in a building such as the World Trade Center where there are hundreds of distinct tenants, the value proposition of everyone in the building sharing a nurse or two would pay productivity dividends for both employers and employees alike. Seeing a nurse would be cheaper than a doctor and could be done without the arduous process of making an appointment.

Encourage government to provide incentives for teleworker programs: Ever notice how many people use their cars to commute to work in crowded metros such as New York City, Atlanta and Los Angeles? Many Americans have back problems and therefore the prudent course of action would be to reduce scenarios where they don't have the opportunity to obtain an optimal position.

We could of course encourage car manufacturers to put better seats into vehicles but this has a long tail. What if we could instead find ways to avoid sitting in vehicles that don't have lumbar supports whether it is a car, bus or train and instead let people work from home where they could have a better potential for good posture?

Insurance, Solvency and Enterprise Architecture

I have been spending some time noodling the requirements of Solvency and believe there are a few fundamental flaws in how reinsurance carriers are approaching this problem space.



Generally speaking, the reinsurance industry introduced the notion of models as a way for private equity and hedge funds to measure the potential risk of loss. The folks who created Solvency requirements seemed to have latched onto the same level of thinking. The challenge as I see it is that carriers are attempting to produce a single model instead of having multiple.

Consider the fact that for facilitative insurance, the re-insurer gets to see the flow as they are afforded and easier and reliable accumulation control where in treaty, at best they only get the information used for underwriting the portfolio at a macro-level. This results in a approach of comparing a scenario where you have high data fidelity with one where their is lower data fidelity.

Another gap as I see it is that the model doesn't drive underwriting and tends to be an after the fact event. Once an underwriter accepts the risk, the reinsurance carrier is committed, then and only then can they incorporate the data entered for the deal into the model. If the goal is to reduce risk, don't you think this process should be inversed?

I also agree that the models fail to account for the differences of property where their tends to be more of a repeatable loss history than on the casualty side.

To argue from the other side of the table, we could also end up with a scenario where the "numbers" and actuarials could over-dominate the human judgement of a skilled underwriter. When we become too numbers focused, we end up with suboptimal results. Look at what has happened with the state of IT for a prime example. Regardless of where you land philosophically, I have been scratching my head attempting to figure out why I have not ran across any online discussions where the practitioners of enterprise architecture have discussed the impact of Solvency on their organization? I cannot think of something that could potentially change how the business works than this. Are all of my insurance EA peers asleep at the wheel?

Social Networking serves to destroy enterprise architecture

Have you observed the vast majority of enterprise architecture conversations on LinkedIn, Twitter and even amongst analyst firms themselves seems to focus more on what the template used is and what tools to use? There is a lack of finding better ways of enabling the strategic intent of the business through the use of technology. I humbly believe that social networking serves to destroy many of the backward conversations amongst enterprise architecture practitioners.



Consider the scenario of being an enterprise architect for a social networking site such as Facebook. Is the goal to focus on application rationalization? Is the goal to perform an inventory of all applications in production so that they can be loaded into an application portfolio management tool? I can't think of a better reference model for enterprise architecture and how IT supports the business than Facebook.

Enterprise architecture within many social networking sites is savagely focused on not letting IT become an impediment to business agility. The focus is less about IT strategy in the strict sense and more about getting the fundamentals of IT right. They are constantly finding better ways to design and build software as well as improving how IT infrastructure teams operate.

I find it fascinating how many enterprise architects can't fathom the simplicity of bespoke enterprise architecture! I have observed that Social networking sites have exhibited the following practices in their behavior:

• a. champion modest code bases
• b. Architectures must be extensible vs all possible functionality designed upfront
• c. Eschew monolithic practices such as writing comprehensive business requirements documents and instead focus on ways to collect feedback from users of the system
• d. Design the ecosystem for growth and do whatever it takes to mask inefficiencies
• e. Don't establish an organization chart that discourages technical people from remaining technical. In fact, encourage the existence of savage teams of nomad developers and encourage them to travel in tribes
• f. Get all the useless processes that don't help people do their job out of the way

So, if you want to be agile, align with the business or other buzzwords of the day, you need to pay more attention to how it is done in social networking ecosystems...

Enterprise Architecture: Ways to make healthcare more affordable...

If citizens of the United States want to ensure that healthcare remains affordable, it has to look at the problem space through the lens of enterprise architecture...



Why am I not surprised to note that no one has studied the supply chain of healthcare? Today, I will share a few ideas that each are guaranteed to save billions...

1. Optimize the pharmacy process: Consider the simple fact that many people have diseases such as diabetes that are long term in nature. People with diabetes typically take the same drug for pretty much all of their life. When does it ever make sense for you to get a thirty day prescription for something you will have for at least the next thirty years? Think about the overhead checking with a pharmacist so frequently costs? Some have extended this out to ninety days but this too misses the point. How much could we save if we could get all our drugs in one shot as an annual event?

2. Change how drugs are dispensed: I frequently purchase prescription medication for family members whenever I travel outside of the United States. My last purchase was in Sangre Grande, Trinidad where I simply handed the pharmacist my money and he handed me a sealed jar. Don't you think this process is much safer than what you witness in your local CVS where the pharmacist is doing extreme and potentially error-prone multitasking in talking to customers, moving pills from one jar to another, disputing with health insurers all at the same time?

3. Make doctor fees transparent: Healthcare is one of the few industries where a consumer learns what it costs only after he has used the service. It doesn't have to be this way. What prevents a health insurer such as Aetna, Cigna or United Healthcare from creating a mobile application that allows a consumer to see list pricing for a given service along with what they could be expected to pay for a procedure out of their own pocket? Imagine a mobile application that could provide a predictive diagnosis and then tell the consumer how much that doctor visit may actually cost upfront?

4. Encourage more volunteerism: I live in a town with a volunteer ambulance system which is much cheaper to run than a for-profit entity. Why can't more municipalities leverage the finer aspects of volunteerism in this regard? Imagine a scenario where a nurse attended a state school such as University of Connecticut and has amassed some debt. Couldn't he/she work off this debt through volunteerism?

5. Make more drugs available over the counter: I, like many other IT employees work in a stress-filled environment and have developed high blood pressure. I take my daily dose of Atenolol. What would happen if they made this a drug that is available behind the counter where you needed to ask for it? It is not a drug that even the most deranged would be interested in taking. It doesn't make you feel good, doesn't introduce any form of psychosis and doesn't even taste good. Why involve the doctor to write a formal prescription, a pharmacist to fill the prescription, etc. Can't we leave these well-trained medical practitioners to do something of higher importance?

Leveraging the worst developer to improve quality of enterprise applications

If you have ever worked in a large enterprise, on almost every project there is that one developer who is absolutely horrible that you wish they would just get rid of but due to HR, you are forced to put up with their suboptimal and ineffective coding abilities. Instead of focusing on how to get them bounced off the project, I believe there is a way to actually leverage them to improve the quality of software being delivered...



Before we get started, I must disclaim the fact that my idea will not work if the challenge of bad developers occurs in scenarios where consultancies such as Accenture have backed up the school bus to your enterprise and sent you more than one or two. That particular challenge is left for another blog entry.

A possible approach is to create a new role I will label as Project Saboteur which will be filled by your suboptimal developer. Their job is to check out a parallel copy of the source tree, and then introduce bugs on purpose. If you have a service that is supposed to return ten values, you deliberately hack the code to return eleven. In theory, every bug they introduce should be caught by an existing test. If not, you've found a hole. Categorize the holes, and you may find systematic weaknesses in the tests. Count the holes as a ratio of overall bugs introduced and you have a very rough idea of the percentage of bugs your tests are finding.

Since we know that this individual can't write quality code, we should leverage them in ways where we need to not write quality code. The art of defect seeding is something that can also test other enterprise processes such as whether the code review process is beneficial or strictly done to appease the PMO organization and is ceremonial in nature.

Defect seeding can be a better motivator for reviewers to more thoroughly seek out and uncover defects. Instead of it being a burden on the team to leverage an incompetent developer, it is better to turn it into a challenge where everyone is incentived to find many of the known/seeded defects. On Agile teams, this tends to add more synergy and zeal to inspection efforts...

What does a CIO do all day?

Does you know what a CIO does all day? Not attempting to be sarcastic but the simple fact that many people in IT can't answer this question with any level of integrity is most certainly problematic...



If you listen to the vendor-controlled media, you would think the only thing they do is listen to thinly veiled PowerPoint pitches from consulting firms and industry analysts sprinkled with a few software purchases. There is more to the job of being CIO than simply best practices in management by magazine.

Is the job of the CIO to push back? When does this mean being an impediment to embracing advances in technology? The CIO must insure new technology will really make things things more efficient. Imagine a world where if everything sold by software vendors were true. You would have achieved a combined 1m % ROI and could run an entire IT department for a large corporation with just one person working part-time but we all know that this simply isn't true.

I am frustrated with vendors and their pitches to save money. Just because something saves money doesn’t mean you buy a new one each year. Imagine a car with greater gas than your current car. If you bought that new car for an extra $5,000.00, you must drive it enough so you actually get the $5,000.00 savings. If you replace it yearly, you never get enough savings to justify the purchase.

So at some level, I think the job of the CIO is to exercise fiscal prudence especially in shops where Enterprise Architects are too busy being conned to pay attention to the next wave of technology. After all, in order for IT to remain viable, it must become business aligned and sadly, most enterprise architects are asleep at the wheel in this regard.

Information Security Control Worst Practices

I was browsing the Forrester community list where there are frequent discussions on information security policies and controls. My observation is that the audit-oriented mindset of controls is a worst practice that is hindering the implementation of sustainable enterprise security...



I think the individuals asking questions regarding policies and controls are sincere. Likewise, I think industry analysts provide answers to questions asked, but never take the next step to figure out if their audience is truly asking the right questions in the first place. There are general worst practices I have noticed:

1. Most controls cannot be implemented: This occurs for a variety of reasons ranging from the state of current technology to the simple fact that many of them get in the way of the business wanting to do business. How many corporations have a ridiculous policy on mobile device usage? How many of these same corporations have actively funded enterprise projects that run counter to them? There are numerous other examples of this type of idiocy. Information security professionals need to get unimplementable "controls" off the book.

2. Most controls cannot scale: The best example of this scenario is how PCI/DSS came up with their requirements. For example, they did a great thing in requiring credit card merchants to take certain steps for their web-based applications. Did you know that the majority of lost credit cards have occurred via websites that are vulnerable to SQL Injection and Cross-Site Scripting? PCI put in requirements that a code review should occur by someone independent from the developer team. Do you think PCI requires its auditors to know anything about software development?

3. Most controls actually ignore sound risk management practices: Most controls use Boolean logic to ascertain whether you comply or not. The reality of security is more nuanced. Imagine the scenario where you did an audit of two enterprise applications and discovered that one has over one-million OWASP Top Ten vulnerabilities but has only two users, is used only one day a year and can be shutdown when not in use. The other application has only one vulnerability but is used by thousands of employees and is Internet facing. Which one will the auditor get their jolly's off on?

4. Most controls are tightly coupled to how a product is implemented: Walk into a corporation and read their controls on passwords. You will note that many of them somehow magically align to how Active Directory, RACF, etc are configured. Now ask yourself, what happens to the control if you don't use passwords in any form but there is otherwise a vulnerability?

5. Most controls are infrastructure-centric and ignore the concept of assets: Is there anyone who thinks the Federal government will shrink its budget? Is there anyone who thinks that the information security department in their own organization doesn't work like the Federal Government? Ever look at how the business invests money? You may discover that they spend more money on applications than they spend on infrastructure, so wouldn't it make more sense to figure out how to secure the applications over securing the infrastructure? Consider the trend of the business moving their enterprise applications to the cloud. Are the controls and ultimately the solutions that implement the controls portable to the cloud or are they only targeted at the internal infrastructure which is increasingly becoming less critical...

Enterprise Architecture: Where have all the developers gone?

Do you remember the Wendy's commercial in the 90's where the little old lady was asking, where's the beef? I suspect many business customers want to also know what happened to all the developers?



When I started my illustrious IT career in high school in the 80s in working for Cigna as part of their Application Field Services division, pretty much everyone in IT knew how to sling code. Nowadays, you are lucky if you could find an enterprise IT shop where 25% of its inhabitants know how to code in a modern language.

Many within the Enterprise Architecture community can wax poetic about the need for business and IT alignment. Few, however have realized that prior actions in the spirit of aligning may have actually moved us further away.

I remember when business customers used to roam the corridors of IT where they would strike up a conversation on whatever they were noodling. They could intellectually test their thought processes against pretty much the first person they found. Nowadays, they are lucky if they get to do this at all, and if they do it is more than likely mired in formalism that takes several weeks to accomplish.

We have outsourced all the developers to different countries in different timezones and now the enterprise architecture team is the last bastion of hope. Is it better for them to focus on meta-issues such as whether to leverage Zachmann vs TOGAF or should they instead figure out how to bring back genuine conversations with the business?

In the age of turning everyone into a plug-compatible human resource, we have managed to make things less human. It used to be very easy for a business person to identify someone in IT. Why did we make it so much harder for our customers to recognize us?

To find a real developer, you must go on a pilgrimage to a dark corner with a strange blue glow, following the trail of Twinkies and Little Debbies and Red Bull can's... You may ask the developer there if he is, but he/she probably won't speak in a language you understand. If the response is incomprehensible, you've found what you're looking for.

Does the business really want better PowerPoint that uses the corporate template when communicating with them or would they prefer a genuine conversation that is thoughtful and timely even if they don't understand it all?

Why "Agile" has only had a modicum of success in insurance

Many people know that I have adopted agile values to the core and that I also work in the insurance industry. I figured I would share thoughts on why Agile hasn't been wildly successful...



1. The majority of leadershipmanagement comes from a project management background: The first acknowledge that needs to occur is one of term confusion. Many do not delineate the important difference between a project management lifecycle (PMLC) and a software development lifecycle (SDLC). The former will gravitate toward project management concepts ranging from Scrum, Kanban or the infamous but otherwise mindless debates over comparing them to waterfall. The later will find value in looking at approaches such as Extreme Programming and building test cases first, however this isn't really visible if you haven't risen the ranks from software developer to CIO.

Let's acknowledge that Agile has been wildly successful in companies and cultures where the engineering mindset is much more valued than the project management mindset.

2. The focus on documentation: Can you think of an industry vertical that outranks an insurance carrier in terms of sending confusing documentation to their buyers? They have a habit of sending 100 page documents such as policies to 90-year old grandma's and couldn't care less about whether it is understandable by the receiving party. So, what makes us think that writing understandable documentation is going to happen?

We can all get caught in the vortex of asking for good documentation, but this is a trap. There is nothing in any Agile methodology that can overcome this challenge. I can tell you from my experience, I'd love a proper requirements document - but I've yet to see one. Every requirements document I see is loaded with assumptions on both sides, and rarely do both sides agree on the assumptions. I had one experience where the customer agreed that one "feature" we were developing for them was totally not what they wanted, but they were afraid to alter the requirements document because they were afraid we'd negotiate out of some features they wanted. So we went merrily along developing something that they would not use. Doesn't think feel like your insurance policy?

When insurance carriers adopt the policy of brevity, then they may stand a chance.

3. IT doesn't know who the customer is?: Having an on-site customer representative is risky, because he/she is bound to be pretty junior. Is the customer really going to spare a senior decision-maker for an entire year? But regardless, the customer representative "becomes" the formalized requirements specifier.

Now, combine this thought with the acknowledgment that many insurance policy administration systems have more tenure than even the most tenured IT employee. Insurance business logic is a collection of exceptions that have been built up over time and has reached the point that no individual even knows them all. Usually, they have been lost in the documentation archives and survive only in code. Therefore, the person that knows how the business works the best in its current state tends to be some lowly IT employee.

The practice I think is best employed is to sometimes go customerless and to encourage IT to adopt the principle that before they write code, they need to learn how to read code.

Is forcing developers to work in cubicles a worst practice?

Last year, you could have found me working in a cubicle on the fifth floor in a building known as North Plaza where I frequently referred to my jail cell as an office. Today, as an Agilist, I have escaped the world of cubicles and am helping others escape as well...



If you think about the role of Architects and Developers unlike other roles, you will quickly see that much of their work is a combination of art and science. Project Management on the other hand tends to be more scientific in its approach. That is if you ignore the point in time where project managers indicate on their status reports that their project is green. On a six month project, they are 90% done and nine months more to go. You know what I am talking about.

Anyway, Programming is an intense activity that requires extended periods of quietness and concentration. Cubicle environments are noisy and distracting. Programming often involves brainstorming (whiteboards are historically one of the tools of choice). Cubicles do not support large whiteboards. Going from a remotely placed whiteboard to the cubicle workstation requires copying the contents of the whiteboard onto paper. This is time consuming.

Programming often involves reading books. Books are best read with directed and controlled lighting (reading lamp, natural light over the shoulder, etc). Cubicles offer overhead indirect lighting shared by all. Books are also best read in comfortable chairs. Cubicle chairs are ergonomically designed for workstations and activities such as typing on a keyboard and looking at a monitor. Even the best of the architects and developers I know, at best only spend 25% of their time typing. So, at some level, cubicles de-optimize the majority of the activities spent done by architects and developers while optimizing the minority of their time.



Artists do not work in cubicles, they work in studios. They need space and natural light. They need a muse. Scientists also do not work in cubicles, they work in laboratories. They need equipment and whiteboards. They need inspiration. If we as IT professionals continue to deliver projects late and of suboptimal quality, then how come no one hasn't put on their thinking hat and figured out that we don't need more methodologies but simply a change of environment?

In a culture where your CIO is craving innovation, isn't it ironic that he/she puts their people in cubicles and then tells them to think outside the box? One trend that deserves further analysis is the teleworker movement. Many corporations in fear of liability surrounding workers compensation claims are mandating that teleworkers establish equitable work environments. While your walls at home may not be covered in fabric, at some level the policy is encouraging one to still work within a box.

So, you can either work in a box at work or work in a box at home. Why are there only two choices? If you have ever visited a large enterprise and truly cared to find the place where productivity is at its highest, may I suggest you visit the cafeteria outside of lunch hours? You will see many having the space they require, convenient access to life's necessities and most importantly the ability to have an open conversation at human tone without disturbing others...

Thoughts on Liferay Portal and Security: Part One

As an enterprise architect, it isn't enough to simply focus on aligning with the business. Stewardship of the technology you leverage within your enterprise (especially when it is open source) is also in order...



My early involvement with Liferay started back in the days of Liferay 2.1 when I created an integration with Netegrity Siteminder. Several versions later, I also integrated with XACML Entitlements Management products from Oracle and Securent (now Cisco). So security functionality has been part of my thought process very early on. Throughout the lifecycle of Liferay I have performed other activities such as being the first customer to get Liferay running on Azul Systems which is a specialized Java appliance that has 768 cache coherent cores.

I had the opportunity to perform the first security review of Liferay by using a now defunct binary-analysis tool from a vendor then known as AppScan. In order to be fair to the community, I will be updating my security analysis of Liferay in two parts, where the first part is to look at the security features of the product and to point out deficiencies I think need to be addressed and to at a later date (over the Christmas break) use two commercial static analysis tools to understand whether Liferay code was written securely.

Without further ado, here are my reactions of looking at the latest version of Liferay through the lens of security:

Enabling/Disabling users: Currently this is represented by a boolean value which indicates that you are either disabled or enabled. I believe that this should change to incorporate reasons for disabling. For example, if an account was disabled for reasons of spam/abuse, that is different than an administrator simply locking an account because the user is on vacation.

Identifiers: Many Liferay objects such as user, group, organization, etc leverage the Liferay counter model which provides an auto-incrementing value that is highly predictable. A better approach to such primary keys would be to support the notion of GUIDs which are more cluster-friendly and less predictable in nature. We no longer live in a world where disk space is expensive, so a few additional bytes won't hurt performance but could increase security.

IDs vs credentials: User identifiers as primary keys into databases should be kept private. There are many places within Liferay especially when interacting via remote services where this identifier is exposed. One optimization would be to have a servlet filter that allows for public credentials to travel over the wire and then be transformed into the private key implementation.

Siteminder: The traditional way to integrate with Siteminder was to either accept a cookie/header or to use the Siteminder SDK. Depending on how the former is deployed, there may be security gaps especially if you deployed a Siteminder agent on the web tier but not the application tier. Anyway, Siteminder like most products is moving away from proprietary SDKs to open standards such as SAML. There needs to be a way of integrating container-based SAML support into the Liferay security model.

Sanitizer: Liferay provides the ability to sanitize content via its com.liferay.portal.kernel.sanitizer.Sanitizer. This needs to be made more configurable (coarse and fine) and integrated with the OWASP ESAPI.

OpenID I am a big fan of OpenID and oAuth but these protocols do work over insecure (non-SSL) channels and therefore believe an administrator should be able to filter out ones provided by users that don't support SSL. Alternatively, for higher assurance sites using these protocols, you should also be able to specify a whitelist of providers.

Administrator: There needs to be two different types of administrators. Administrators that can create users and administrators that can create other administrators. You should also have the ability to restrict where adminstrator-level accounts can access the environment from. There would be something strange if an administrator who happens to be currently out of office accessing a bank site running Liferay from Iraq at midnight.

User Management: Liferay allows the ability for an administrator to open another browser window and browse the site as though you were the user. Imagine a scenario where you are using this on a company Intranet site and had a payroll portlet. There needs to be a way of specifying in the portlet's security model that this can only be seen by the real user and not via impersonation.

ServiceBuilder: This utility is used to describe a model's class and attributes. What would be a better place to describe the requirements for validation than here? Imagine the ability to tag an attribute with a Regular Expression that could provide validation capabilities. ServiceBuilder could ideally do several things with this information ranging from creating the appropriate database constraints to providing consistent validation whether accessed through portal or remote means.

Resources and Permissions: Liferay has a wonderful permissions framework that can handle many finer-grained authorization decisions but this still has certain gaps. The first gap is that you have to add resources into the permissions system by calling an API. In the scenario where you may want to implement something analogous to an XACML obligation, this model will require you to implement a new portal hook for each object type that only calls the addResources method so that you can then integrate it with a subsequent permissions call. For example, if you wanted to use the permissions framework to create a way for select portlets to be "available" during specified hours. An alternative way would be to allow for a given portlet/resource to support description of permissions in an extensible manner via its XML configuration.


Anyway, there are probably other things that I have not yet thought about but probably could be weaknesses, so all disclaimers apply. With that being said, you should feel confident in the fact that while no portal is ever 100% secure, there is a vibrant community looking out for your best interests when it comes to security and that Liferay is leading the pack in this regard. Something that cannot be said of many commercial implementations. Take note Gartner and Forrester...

An Enterprise Architecture viewpoint on state government...

In the same way a parent coaches their children to save money and be fiscally responsible, I humbly believe that the federal government needs to do the same for the states and local government...



Instead of making fun of the government and its approach to enterprise architecture, today I will instead propose three ideas that can help save all of us taxpayers money. Many people know that I am a registered republican and fiscal conservative. I am also passionate about encouraging others to pray, fast and be charitable and will look at government issues through these lenses. So, here are the three ways government can save money:

Implement a volunteer police force: Consider the scenario of how much of our budget is spent on law enforcement. Now consider the fact how it could be reduced if we allowed for volunteerism to enter the equation. My own background includes being honorably discharged from the United States Coast Guard which is not only a military fighting force but the police of our waterways. I can volunteer to get shot at by foreigners by enlisting in the military, I can volunteer to die in a burning building as a fire fighter but I can't volunteer to do traffic duty at the annual Thanksgiving day parade nor sit in a parked car with my lights flashing at a construction site?

Make English the official language: Have you ever considered how much additional expenses associated with printing and translation occur to support forms in other than English? Allowing volunteers to serve as translators has several additional advantages. First, when you take someone from the community and put them into a role that helps out others, you allow the government to form a more cohesive bond and can even provide support for languages not officially supported. You also make it easier for people to get government jobs and therefore can lower the pay scale if you had less requirements related to language. For example, if you wanted a state employee who knew enterprise architecture, speaks Spanish, Arabic and COBOL then your pool is limited. Once you remove the language restrictions, the job pool is increased making it fairer to all the citizens of the government to apply.

Consolidate identification systems: In the State of Connecticut, I hold various licenses and permits. Don't you find it a big waste of process in that the State Police administer a separate photo ID than say the department of motor vehicles? Of course you are asking yourself why would the state police trust DMV to issue a permit? While there needs to be additional due diligence at initial application time, why do you need it at renewal? In the state of Connecticut at each renewal, I have to prove that I am a citizen. I was a citizen when I first applied and kinda think that the odds are pretty good especially for us folk that are born in the United States that we will be a citizen in the future. For those who will argue that I could renounce my citizenship, I guess I would ask the question of why does this even matter? After all, I already got weapons that I purchased when I was a citizen anyway.

Did you also know that in the state of Connecticut, permits related to the building trades are governed by the department of public safety who also runs the state police? Why can't I renew my electricians and radio repair permit at the same time and same location? Taking this one step further, did you know that the state of Connecticut has non-police officers at the handgun permit desk doing renewals but if you want to renew your boxing (pugilism) license, it is handled by a police officer? Does this feel backwards to you?

Is your CIO an Agile Leader or a Conservative Manager?

Being Agile is the antithesis to being conservative. Agility while focusing on short-term delivery does not mean that you cannot take a long range approach. Having a clear vision for the team to rally around and the need for managementleadership to think ahead to ensure that we're not just moving forward, but moving in the right direction is of utmost importance...



If Agile is the antithesis to being conservative, would it be a far stretch for us to acknowledge that annual planning is the antithesis to innovation? Agilists are out there, every single day, responding to change, creating things no one has before. Agile leaders are open to new ideas, willing to take risks and comfortable with agile's level of change. If your CIO believes he needs a PMO organization to govern planning cycles then is he responding to change or more focused on creating documentation that can impede yet undefined forms of innovation.

Agile teams are about trust and couldn't function nor deliver without it. Leaders encourage trust by enlisting team member's strengths to achieve results and giving the team autonomy to make their own judgments about the best way to meet objectives. Managers on the other hand are savagely focused on taking care of HR review processes where the focus resides solely on one's competencies.

Agile leaders are passionate in ways that make the masses feel good about themselves, their employers and society at large. Managers may also exhibit passion but the feeling of warmth is only felt by the priveleged few. One way to spread passion is by also spreading empathy and caring for others. The best amongst the Agile community care about the human condition and will enquire first about your health and well-being while managers will only care whether you got your timesheet completed on-time...

Are Enterprise Architecture Practitioners obsessed about the right things?

Many of the LinkedIn groups focused on Enterprise Architecture practices seemed to be overly obsessed metamodels, templates for documenting an architecture and coming up with the latest taxonomy/classification scheme for organizing work. If enterprise architecture is about helping the business realize its strategic intent through the use of technology, any rationale person would conclude that much of our conversation is wasteful in nature...



Too many practitioners wax poetic about the need for IT to align with the business but haven't developed a fundamental under of the business. This is honestly less about what your employer sells but in a more holistic sense what is business.

In my travels, I have seen lots of enterprise architecture artifacts and even a few attempts at business architecture artifacts and have came to a profound conclusion. Much of this work yields to perceptions that don't reflect present realities! How many architects of any flavor can point to any artifact they have created that demonstrates the full reality of their company, line of business or even organizational unit? Does it describe the situation, characteristics, culture and challenges the business truly faces?

Some enterprising architects may have familiarized themselves with SWOT analysis and they should get kudos. For those that haven't, then maybe they need to do some quick homework. While a SWOT analysis will demonstrate an organization's strategic advantages and disadvantages, what artifact is responsible for capturing an organization's myths and blind spots?



Have you been following the Occupy movement? The vast majority of Enterprise Architects I know are part of the priveleged 1% and therefore have focused on the fact that their message is confused. I believe though that there are some gems from this movement we can all learn from to make our own employers better, our outside of work life better and more importantly our communities in which we thrive better.

Let's face it, the masses of the Occupy movement as well the majority of Enterprise Architects have no awareness of the big economic picture. Blissful ignorance of the global reality of capitalism and competition isn't something that should be tolerated as it is a key requirement for alignment and sustainable innovation. We should as practitioners of the discipline of enterprise architecture understand how capitalism work, why capitalism won, how dynamic economies are created and destroyed and most importantly why it is raging across the planet!

If we can't understand macro-level trends, then how can we be certain that our micro-level enterprise-oriented recommendations are sound? Too many of us mistake innovation as being simply a proxy for doing things better, faster and/or cheaper. Even more of us think that process can be a sustitute for competence. Reality dictates that we should attempt to understand not just the changing people demographics and their purchasing habits but why some companies are winning and others are losing in the marketplace.

If a butterfly flaps its wings, does it cause a tsunami in Japan? If a dictator on the other side of the planet deregulates their marketplace, eliminates government monopolies and pursues open markets, do you think this should an impact on your enterprise architecture...

Enterprise Architecture: Is commitment a worst practice?

There is one sure thing that will kill any project! That is the belief that you must give yourself utterly to it. It's the death of marriage, it is the death of any work environment. To say, I must deprive myself of other things while I give my attention only to you in a foolish practice within large enterprises...



In an enterprise setting, commitment comes in many forms. First, there are people who are committed to adhere to office hours, nothing more, nothing less. The flip-side of this is that without an insistence on standard office hours, there are many that would work far more than they should. If a conversation with human resources starts with the notions of a forty, fifty or whatever set hours a week, then the enterprise is doomed to mediocrity.

Agility isn't achieved by standardizing the number of hours worked but by focusing on achieving a sustainable pace. The McGovern principle of work/life balance starts with acknowledging that you can only work as hard as you rest



The whole problem is a result of bad management logic where the thought centers around the notion that a time-clock is an accurate measurement of payment for work done. It's resultant from either a manager that can not comprehend what developers do, or a manager that is too far detached from the daily work of the peons.

For the record, I am not advocating doing away with the timeclock. In fact, I believe there are certain cases where it could be leveraged. If a person can get their work done in three hours and can get time to slack off, they can pay back some of their decompression debt.

In the same way that refactoring pays down design debt, The more overtime you work, the more "decompression" you need in the form of vacations, short-hour weeks and "dead air" (time spent at work not doing anything useful -- or worse, doing actively stupid things). If you never need any decompression, you can continue indefinitely. Sometimes you need to steal some hours now (to finish a project) in exchange for extra decompression later.

The problem is that most projects and leaders managers rack up the debt and only make the minimum payment -- they try to do a bunch of little things to keep the overworked developer happy without solving the problem that made him unhappy to begin with. As a result, the developer begins to cost more and more to keep: bigger raises, more "personal days", more inactive time at work, negative effect on others and so on.

So, going forward you need to encourage commitments where it makes sense and likewise ask for commitments that don't violate other commitments...

Thoughts on Forrester Analyst Communities and Transparent Research

I currently participate in Forrester's various communities and like the interaction with many of its analysts. With that being said, I think there is much room for improvement....



So, here are a list of improvements I would suggest to make Forrester's communities much better...

1. All analysts should be encouraged to participate: In the communities I participate in, the majority of Forrester analysts are missing in action. Being community-oriented shouldn't be left optional nor thought of as something done in one's free time between billing clients. Forrester needs to make this activity a first class citizen and incorporate participation metrics as part of an analysts annual review cycle.

2. Communities should be more tightly linked to reserach: Have you ever noticed that the pretty much all of the analyst content is static and never changes after it is released? Wouldn't you think that if hindsight is 20/20 there would have been opportunities to update previously published research? More importantly, have you noticed that analysts aren't replying to comments left on their research and defending the research position vigorously?

3. Why are analyst firms immune to attribution?: The community brings with it insights that the analyst would not have came up with on their own. Why is it so difficult for analysts to acknowledge this insight in the opening of their research? Don't you think you are doing the community a disservice by not acknowledging their contributions?

4. End users have their own research agendas too: Wouldn't it be great if they were acknowledged, harvested and assigned? While it is noble for an analyst to propose their own research, shouldn't there be a mechanism that is fully transparent where one could propose and see the workflow behind the proposal?

5. Research shouldn't be the sole domain of analysts: Communities are more than capable of creating and publishing their own research. Why wouldn't Forrester want to become the destination for all community published research released under Creative Commons for example?

Thoughts on Cloud Security...

It would seem to me the focus on the security posture of cloud security providers is well, misfocused...

Let's face it, many cloud providers use the same underlying technologies as large enterprises. This may include various flavors of operating systems such as Linux to virtual machines such as Java or .NET. They will also be running some form of virtualization technology to provide the fundamental isolation from other tenants. So, shouldn't enterprise be worried less about the security posture of any individual cloud provider and instead focused on the security of software deployed regardless of whether you run in the cloud or not.

There are obvious practices an enterprise can leverage before deploying their application to public cloud ranging from the ability to encrypt all sensitive information, to even running your application across multiple cloud providers but security of the cloud still isn't guaranteed in that if the software stack used across all the providers is insecure, then you will still get compromised...

The missing relationship between Enterprise Architecture and Procurement

Isn't it fascinating how procurement departments negotiate enterprise agreements without an understanding of the roadmaps or even the unarticulated strategic direction that enterprise architecture team wants to drive towards...



Many software license agreements are not a fit for their intended purpose. Many contracts fail to explain clearly what the buyer has to measure to stay compliant, place unreasonable restrictions on usage and/or deployment and of course can be an impediment to the enterprise taking advantage of cloud computing.

When these two groups aren't communicating, it is guaranteed that this will result in unexpected software costs and audit costs. The communication however doesn't end here as it is important for the vendor to also participate in the conversations. Generally speaking, many enterprise architects ask thoughtful questions of vendors but fail to get how specific scenarios should be handled in writing. Lawyers that work with procurement teams are very good at getting in writing what was agreed if you can explain it clearly with relevant examples. Oral descriptions of policy and promises that "we never enforce that" are insufficient.

Another missed opportunity is for the enterprise architecture team to periodically recheck existing license agreements to see where they may need to be amended. Generally speaking, much of the license renewal ceremony revolves around keeping down costs, but this isn't an excuse to also ask for several new considerations. After all, you are much smarter now than you were when the agreement was negotiated. If the enterprise architecture team isn't providing input, then this is criminal...

Ten Interview Questions for Enterprise Architects

Want to find top talent? More importantly, want to know the types of questions I would ask if you had to interview with me? Below are ten questions you should ask of enterprise architect candidates as part of the interview process...



I have decided to make this a two-part blog where the first part is simply to present the questions with a followup as to the importance of them.

1. What type of work do you want to be doing five years from now?
2. Do you think that if the Federal Government had top talent in its enterprise architecture team, would the deficit be lower than it is today?
3. What does work/life balance mean to you?
4. Do you write code outside of work?
5. What was the best and worst software project that you've been part of?
6. What was the defining characteristic of the best and worst boss you have worked for?
7. What would you recommend in terms of enterprise spend for security. Would you target more money for infrastructure or for applications?
8. How should enterprise architects be involved in the pursuit IT outsourcing?
9. What value proposition could cloud computing provide to our organization?
10. Are you on LinkedIn? If so, do you participate in a larger enterprise architecture community?

Enterprise Architecture: The Era of Silence

It would seem to me that if Enterprise Architects wanted to improve the quality of enterprise application development, they would beat their PMO silly with wet noodles for designing processes that allow for the era of silence...



Increasing, many enterprises are convincing themselves that they adhere to Agile methodologies, yet somehow they have simply hijacked the vocabulary of SCRUM and are still waterfall in their approaches. Even for enterprises that are honest enough with themselves and have acknowledged that they can't be anything but waterfall still need to take the next step forward and acknowledge the existence of the era of silence.

The era of silence is the extended period of time, often measured in six to twelve month increments squeezed in somewhere between completing the analysis of user requirements and the big bang testing phase. The era of silence is only broken when discussions betwen development and the customer occurs on the predictable status of the development schedule.

We all know that an enterprise and their PMO organizations love process, but how come we are solely focused on process steps and governance gates at the expense of building better software? Wouldn't it be wonderful if a PMO didn't focus on what artifacts we produced on what dates vs focusing instead on ensuring that large expanses of time don't occur without everyone involved in the SDLC truly collaborating...