Enterprise Architecture: From Incite comes Insight...

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...

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?

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...

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...

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...

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?

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...