Enterprise Architecture: From Incite comes Insight...

One of the more annoying practices that occurs in the blogosphere is when architects use the same tactics as non-technical project managers by attempting to find happy mediums in conversations. One on hand, they believe that healthy tension is good and that there is a knowledge crisis in our profession, yet on the other hand, they don't want to see meaningful conversations occur where new insights can emerge...



Throughout our profession, many of us have ran across that non-technical project manager who believes that they are adding value by moderatingfacilitating conversations between technical individuals. One technical resource may think it will take say fifteen days to accomplish a task while another technical resource may think it will take say fourteen days to accomplish a task. The non-technical project manager will rally the troops and discuss the discrepancies. The non-technical project manager will demonstrate their authoratative leadership (fyi, don't step in it) by boldly asking two parties if it is fourteen days or fifteen days and noting that there is no agreement and will ultimately make the decision themselves.

In this situation, the non-technical project manager has yet again failed to realize that in their disillusionment of adding value that they have in all reality shut down a useful conversation that needed to occur. Maybe if they recognized that to the untrained eye what appears as a dispute really isn't.

Maybe I am in the wrong profession. After all, I have flown on airplanes before and I do know how to provide a tune-up for my lawn mower. Maybe this makes me highly qualified to mediate discussions between two aircraft engineers over at Pratt and Whitney. I could learn all the buzzwords that the engineers use and help design better jet engines. Who in the blogosphere wants to fly on the first flight with me?



Many folks throughout my career have heard of the 7.42 thesis where if two technical resources are being questioned by someone with an untrained eye as the moderatorfacilitator that they should immediately state an arbitrary level of precision made up on the fly which will signal to the other resource that this conversation isn't really worth having and should occur in an environment at another time where healthy tension is appreciated.

Some folks will get it twisted and still won't get the point. Consider, the walk to lunch where you may observe to engineers A and B where A is ranting about the code of say Engineer C. You may observe a conversation that sounds like (I made the conversation politically correct so as to not offend ) "Man, person X bugs me. Have you seen his code? Whoa! unreadable. I am surprised it compiles. Totally wreckless..."

9 times out of 10 if you put Engineer A and Engineer B in the same room, you'd be unable to discern that there was an actual issue because they'd treat each other professionally and with courtesy. The issue will often resolve itself or just be that... an issue. Where you're going to need to get involved is where the angst is real and potent and, well, as emotionally charged as I've ever seen in IT... the bug database.




Imagine if healthy tension and if conversations where never allowed to emerge. Would we all think the world is flat? Would we all think that waterfall methodologies are sound? and that Hamas is bad for the Middle East? I wonder if healthy tension were to occur whether we may conclude that the world is really round, that there are better ways of developing software and that democracy in the Middle East is good for all.

Most enterprises have done a wonderful job in creating healthy tension between engineers and the QA folks. I would rate this a level four on the healthy tension maturity model. Five is harder to obtain since it would require the QA department to not be viewed within the industry as the training ground for Junior IT folk. Likewise, if you have achieved a five, the ultimate goal of shipping a product may never happen. Where does the maturity meter rest when asking the same question of healthy tension between architects in the blogosphere? I would say it is a two but of course there is someone that is willing to debate. The answer doesn't really matter as the dialog is more important.

Some organizations attempt to avoid healthy tension and prefer propaganda based approaches of attempting to get everyone on the same page. They hang up posters and pat themselves on the back but never really ask the difficult questions of themselves. Usually organizations such as these ultimately fail. Failure is manifested in several ways including blown IT budgets a mass exodus of truly talented individuals and lots of individuals simply going through the motion without passion or personal committment.

Part of the learning process starts with figuring out the right questions to ask. This is my first attempt at seeking the advice of others...



Here are eight questions I would love to see answered by architects from corporate America who blog:

• Blogging: You folks blog and participate in the blogosphere. Have you ever encouraged your boss to blog? If not, would you mind sharing the reasons?


• Strong Technical Leadership: Do you think strong technical leadership is a predictor of success within an enterprise architecture discipline?


• Healthy Tension: Blogger James Tarbell believes that an architect and project manager have somewhat opposing goals which creates healthy tension. Do you believe that healthy tension is frequently practised between enterprise architecture groups and program management? If not, what do you think should occur to increase the amount of healthy tension?


• Governance: Many bloggers get it twisted and are of the belief that governance is all about process. If one were to look up the word in the dictionary it is more indicative of behavior than process. Has anyone ran across any large enterprises that have true governance processes that measure behavior? If so, what are their best practices?


• Project Management Professionals: Just because someone may report into the "IT" organization doesn't make them an IT professional. A business analyst can be in an IT organization or in the business organization. Likewise, a project manager and their skills are not really IT, they are project management. A project management discipline is equally applicable to construction, restaurant catering or sanitation work. If you were for a moment believe in the refined defition I am using, is IT really shrinking? I kinda believe that IT jobs are not being lost to outsourcing, just jobs of folks in IT organizations.


• Government Enterprise Architecture: One can acknowledge that the Federal government is probably the largest practitioner of enterprise architecture. It is wonderful that they have an act of congress: The Clinger-Cohen Act mandating enterprise architecture on all parts of government. Likewise, it seems as if their enterprise architecture is more about creating rigorous process and comprehensive documentation that no one actually reads. Does the folks in the OMB actually track ROI on EA efforts? Do folks that practice federal EA ever consider seeking advice from folks who practice it in corporate America?


• IT/Business Alignment: This is a popular phrase in many magazines. I am curious if others have a mental model to know when this can be taken too far. If everyone is busy aligning with the business, who is paying attention to technology?


• Open Source: While I have on numerous occasions shared my own personal thoughts on open source, I am curious if others believe that enterprise architects have a fidicuary duty to represent all forms of software as potential solutions within their enterprise and not just closed-source commercial offerings? Open source of course can be about free (in terms of price) software but I refuse to limit myself to this kindergartner level of thinking. Open source is also a model for software development. Could open source as an agile method enable agility?

Several additional questions for industry analysts...

• I periodically talk with industry analyst firms who may provide me with a "lead". In turn, I will usually provide feedback to them on whether it worked out or not. The curious thing though is that many corporate buyers of analyst research tend to think of industry analysis as a one-way street. I believe that providing feedback helps make everyone better. The funny thing is that no one has ever asked me for feedback but of course I given it anyway (Command is one of my strengths). The real question is do analysts really want feedback and if so, how come they never ask for it? Is there such a thing as best practices for giving feedback to industry analyst firms?


• James Governor of RedMonk has been posting on What do "numbers" analysts do. I don't want to be guilty of reading into his posts but there seems to be a hint that customers of industry analyst firms are moving away from quantitative analysis towards qualitative analysis. Could someone quantify whether quantifying or qualitative analysis is more important to today's enterprise?


• The discussion around open source still seems to be around software vendors with something to sell. There are large Fortune enterprises such as Duke Energy who have nothing to sell in terms of software yet have openly contributed wonderful projects to the community such as their DUK.NET Application Framework. What should they be doing to get their story told? How can other Fortune enterprises that would benefit from hearing their story actually get a chance to?


• I am in a somewhat weird situation in that I can be a customer and vendor within the same conversation. This year on my radar at home, I plan on contributing code, insight, etc to Liferay Enterprise Portal, ServiceMix (Extremely scalable ESB), Xen and possibly Shibboleth. I am not interested in just contributing to add value to the community at large but have an equal need to take care of my own big ego. Simply, I would like for these products to show up leading categories on industry analyst rankings. Getting into innovative, promising, etc type categories doesn't meet my own requirements. In short, I want to move the needle but can't figure out exactly how to do this in terms of these products. Can someone tell me what features these respective projects need in order to gain the number one spot?

Awhile back, I asked several questions regarding Business Rules Engines and BPM and while I didn't get any clear responses to many of the questions, I think I may have started to figure out the answer...



Many workflow engines use rules engines at their core. I am of the belief that they do differ in a couple of regards, including but not limited to:

• Workflow related rules don't really have any notion of vocabularies. Curious if they should?


• Business Rules used in rules engines use declarative constructs where one declares conditions and then later also declares negation conditions. Rules within workflow are if/then/else constructs.


• Business Rules engines use the RETE algorithm invented by Charles Forgy whereas workflow rules dont. Maybe folks haven't figured out how to apply RETE to human-oriented processes? Maybe they could skip Six Sigma type process optimization and go strictly RETE?


• Somewhat point in time, business rules engines provide finer-grained tracking and analysis of rules than workflow engines do. Not sure though what this means in terms of enterprise modeling?

May need to revisit prior thinking on the most scalable enterprise service bus in existence: ServiceMix. Anyway, Am I on the right track?

This is the only industry conference you should attend this year...

Several days ago, A fellow architect and I were walking on our way to work and I noticed that he had a faded yellow ribbon on his car. I commented on the fact that since it was faded, he obviously wasn't displaying the ribbon in support of our troops as a fashion statement and truly believed we must not only passively show our true colors but encourage others to do the same...



In this conversation, he mentioned that he served in the National Guard for six years. I myself, served in the United States Coast Guard. Later in the day, we happened to bump into each other again along with another architect named James and started talking about agility whom happened to serve in the Marine Corp. It kinda dawned on us that a pattern started to emerge. There is a high affinity to architects who believe in Strong Technical Leadership to also be prior military.

We start to reflect on our past jobs and think about all of the wonderful experiences we had working with others in the past and realized they were the types to also have an affinity to the military. Likewise, we also realized that those who went into project management were less likely to have a military background. I guess part of the rationale behind this is that the one thing the military doesn't teach is how to gain buyin.

On many enterprise projects, a project manager will rally the troops and attempt to gain consensus. On the battlefield, if you are a private you simply put your trust in the Sargeant as you know the mission will be successful. You know in your heart and soul that you can trust your Sargeant because he has been in truly life or death situations in the past and has emerged multiple times successfully. Likewise, a soldier goes into battle knowing that he will never be left behind and that every single member of the team has his back. The soldier knows that unless he violates the code of conduct, the sargeant won't be sabotaging him to commanders higher up and if the sargeant did such a thing, the sargeant would be the one to receive the full force and wisdom of leadership.



I wonder in the age of diversity and inclusion, we have conversations around gender, race, religion, nationality and sexual preference but never around military experiences. Folks with prior military experiences obviously think differently. After all, having enough resolve to go into battle knowing that you may never come back is real. In the Coast Guard, I remember being in basic training in Cape May, NJ reciting the general orders while inhaling tear gas. I remember the feeling of what it feels like to be close to drowning. I remember taking aim at a target with my rifle and not just envisioning it as a piece of paper but as another person that may be attempting to cause harm to me and how I not only had to think about stopping their actions but had to be swift and deliberate and enter the frame of mind to utterly destroy them.

The military changes everyone it touches. There is no such thing as an Ex-Marine or Ex-Coast Guard. It is always with you. We are now in a world where this type of thinking is no longer appreciated. Folks with military experience are less and less rising the corporate ladder to the detriment of us all. I wonder if the value systems of America mirror the value systems of the enterprise? I wonder if folks have truly figured out why enterprise architecture is noble but has only delivered mediocrity? I wonder if it is already too late.

If you happen to be an industry analyst or CTO of a startup and come across these words and have prior military experience. Please leave a comment. I hope I am not alone in the wilderness and have been abandoned...



On the way home, I drove a grocery store to pick up some ethnic items where folks who arrived here on H1B Visas frequent. Noticed that there is no sense that they even have a minute amount of responsibility or consideration towards supporting our troops. I engaged in a passionate conversation with one individual who was talking about tragedy in their country of India and how they supported charity there. I asked he felt it was worthy of him to contribute a tiny amount to charities that benefit people here such as the wifes of the troops as they are what makes America a place where you can work and send monies there. No response...

Don't get it twisted, as I am not interested in forcing my value system upon others. I do though, would like to see folks who arrive from other countries to not think so insular and expand their horizon of thinking. I think that my fellow architect also caused me to take a pause for a minute to think about what is really important. Hopefully, I can figure out better ways to support our troops. In thinking about this, I realized that I have never even talked with my children about the importance of this issue. Anway, If you are foreign-born, please click this link and consider donating a couple of bucks to the Books for Soldiers campaign.

A couple of days ago, I was in the hallway at work and asked two peers of mines to provide me with honest, candid feedback on how I am perceived. Figured I would share one of their recommendations on something I needed to work on...



Strong Technical Leadership while sorely needed within most enterprises simply isn't enough. The main problem is that the vast majority of management in a large environment may literally think about fifty things a day which only leaves time for about fifteen minutes at most to understand anything. Of course most technically competent people who aspire to be leaders may have read books such as the Seven Habits of Highly Effective People and may have even tuned into the notion of "seek first to understand then be understood". The problem may be with technical folks the part about being understood. Management is not ignoring you, they simply don't have the time to understand anything. Therefore for an enterprise architect to be successful, he must develop an elevator pitch.

An "Elevator Pitch" is a concise, carefully planned, and well-practiced description about your company that your mother should be able to understand in the time it would take to ride up an elevator. Having worked for a couple of Internet startups prior to joining corporate America I was of the belief that I had a handle on what the elevator pitch was. Sadly, it didn't occur to me until recently that the 30-second elevator pitch used by CTOs of Internet startups is a little different than what Enterprise Architects need to practice in corporate America.



I have provided advice in the past to Software CEOs and venture capital firms as to better ways to appeal to selling to me aka "the elevator pitch" only that this occurs first over the phone or via email but figured I would at least share what the pitch should contain:

1. What is your product or service?
   
   Briefly describe what it is you sell. Do not go into excruciating detail.


2. Who is your market?
   
   Briefly discuss who you are selling the product or service to. What industry is it? How large of a market do they represent?
   


3. What is your revenue model?
   
   More simply, how do you expect to make money?
   


4. Who is behind the company?
   
   "Bet on the jockey, not the horse" is a familiar saying among Investors. I believe the CTO is the jockey and if you got a famous one, don't hesitate to let me know. Send me the URL to his blog if I dont. If you have a strong advisory board, tell them who they are and what they have accomplished.
   


5. Who is your competition?
   
   Don't have any? Think again. Briefly discuss who they are and what they have accomplished. Successful competition is an advantage-they are proof your business model and/or concept work. If you can't tell me this then the only thing I can conclude is that you have an expiriment not a business.
   


6. What is your competitive advantage?
   
   Simply being in an industry with successful competitors is not enough. You need to effectively communicate how your company is different and why you have an advantage over the competition. A better distribution channel? Key partners? Proprietary technology? (sometimes proprietary technology is OK, sometimes not);

The main problem is that this form of elevator pitch has works well for software startups but has no lift in corporate America. Venture Capitalists sooner or later spend time analyzing the financials, getting the pitch validated by others and so on. Sadly, this time never comes around in corporate America. I have noodled the idea that the corporate pitch has different characteristics. I have came up with the following five attributes:

1. A "hook"
   
   Open your pitch by getting the person's attention with a "hook." A statement or question that piques their interest to want to hear more.


2. Some notion that they will get fired if they don't listen
   
   Folks like to know someone has their back and appreciate that one is looking out for them.
   


3. No more than 100 words
   
   Your pitch should go no longer than 40 seconds.
   


4.  Passion
   
   Management truly doesn't understand technology can only within the small time they have measure passion and energy from whomever is representing an idea. Mediocre ideas stated with passion are better than game changing ideas that can make millions of dollars stated with facts alone.
   


5. A request
   At the end of your pitch, you must ask for something. Do you want them to open a door for you, talk to their boss about the idea, etc

As you are probably aware, most enterprises at this time of year enter their annual review cycle which makes us behave differently. I previously mentioned in a past blog entry how most technical folk are absolutely horrific at self-evaluation. I hope that I can figure out how to become mediocre at it. Anyway, I hope to see how well my thinking on this topic works over the next couple of days with a handful of IT executives (I really hope they aren't reading my blog and think of themselves as one of my expiriments). Hopefully though, I will openly try it on my fellow peer and blogger JT. Maybe he can chime in a provide additional insight...

Early in my career, pretty much everyone within IT knew how to write code. Nowadays, if you find more than 40% of the employees in any IT shop within a Fortune 200 enterprise that knows how to code, one would be in heaven. Was noodling the thought that if enterprise architects are supposed to increase speed-to-market and reduce total cost of ownership, they need to figure out how to get stewardship over the project management function...



Fundamental project management and those who practice it should minimally know what the status of any project is, how much the project has slipped from either original schedule or features, what are the impediments to delivery and what can/should be dropped in order to increase efficiency. While the call to action at a philosophical level is simplistic, in practice it is harder than it may seem.

I recently discussed the notion of Enterprise Architecture and Humility and think a similar pattern occurs in project management which is the illusion that they actually have control. Recently, I had a discussion with architects who work across the street from me and they have figured out that the reason that while technical folks embrace Agile Methods while non-technical project management will resist lighter weight approaches is that agility doesn't support the notion of impression of control that methodologies such as Six Sigma and CMM provide.

Another problem is that impression of control emerges within large enterprises by the creation of Project Management Offices. Usually these folk tend to value consistency over productivity and fail to acknowledge that the vast majority of truly successful projects (this is different than those who were mediocre but had a positive spin put on them) usually rolled their own "methodology" to suit the needs of the project and the people who were active participants on them.



Every team within an agile enterprise should have the opportunity to choose their own culture instead of being forced to blindly inherit the culture of the previous incarnation. It is useful to copy/emulate a successful culture but this decision should be made by its participants not outsiders who don't have skin in the game when it comes to delivery.

Alistair Cockburn has a wonderful document entitled Just-In-Time Methodology Construction that is worth a read.



I remember when I started in IT, we used the term "Project Leader" and am actually happy we went away from this term. I guess many folks within the enterprise have realized that there is a difference between management and leadership. Leaders are difficult to find while managers are commoditities. Some folks still use these two words interchangably but are truly missing an opportunity to make the enterprise better.

Maybe enterprise architecture should take IT back to its roots. There were two parties in the enterprise, those who wrote code and those who were business customers. There were no specializations of technical resources and folks understood all layers of the stack. Likewise, the business and the notion of project management was just part of what business management was and what business folks did.

During the bad days of my own career, folks within IT were given more "important" tasks that somehow were rationalized to be more important than actually delivering valuable working software to our business customers. Over time, the notion of project management instead of being something that is done as part of one's job became a full-time job for professional project managers. Of course this was justified in the name of increased productivity, but if you were to back-test this notion, did it really happen?

What would happen if enterprise architects started asking IT executives if project managers should only be providing value to management at the expense of the team? In my own travels, I have banged my head into my cubicle everytime a PMI certified project manager who hasn't written a line of code in their lifetime walk up to me and state: "I need the following information or I can't get my job done!". when did information become more important that the target of the information itself?

Maybe project management and all of its ills are things that cannot be changed and are too entrenched. The one thing though that I can say is that I will become more savage going forward in making sure enterprise architecture in any shop doesn't follow this same path. Maybe this is an opportunity in disguise. The enterprise needs leadership and since project managers have no interest in being leaders, us enterprise architects should seize the moment...

I was reading Jeff Schneider blog and thought he nailed it in discussing the problems that the vast majority of enterprises face when adopting SOA. Many enterprises are attempting to leveraging existing systems vs rewriting them from scratch. While this may save money in the short-term, it will surely cause problems down the road. For those who are attempting to introduce SOA approaches and apply them to legacy architectures may have multiple problems on their hands...



SOA is a paradigm shift, folks who have traditionally worked in legacy environments more than likely have no in-depth understanding of SOA nor have any interesting in learning more. They do so because they are pessimistic by nature and believe that everything has already been done before but only under a different banner. We all know that pessimism in general can ruin projects, but when one has a pessimistic architect as a technical leader, it is pretty much doomed to fail...

It is irrational to think you can do paradigm shifts by doing more of the same. A paradigm shift requires different thinking and most importantly new approaches. That's its point. Some folks attempt to take on SOA and either totally fail or only have marginal success and resort to creating wonderful IT marketing turning effort failure into a success. Usually the consistent pattern in these shops is when enterprise architecture types set the expectation that 100% of all projects will succeed.

Falling back to something that legacy architects may be familiar with is the Rational Unified Process and how it prioritized: People, Process and Tools in that order. If an enterprise figures out how to focus on people first, they will get the notion of what the first two words in service-oriented architecture means.

A better usage of legacy architects is to focus them on the business domain while allowing those who understand the technical domains to emerge as leaders. Architects who have went through the paradigm shift sometimes gain valuable insight into the inner workings of the business application and innovate new approaches. Legacy architects usually have over time developed sufficient expertise and influence to suggest changes in business process to make them more efficient. Presenting ideas to the business customer can at times require skillful sales skills. In the business world, it is sometimes more important to be liked than be right. Of course this causes a culture clash amongst those with integrity but in being service-oriented from a mental model helps both types find a chaordic balance.

Most folks in the enterprise don't operate from a mindset of logic nor discipline as "influence" rules the day. Maybe we can start influencing them to the fact that enterprise architecture is not software architecture. Some people explaining enterprise architecture is like city planning while software architecture is like building design. While I really, really don't like the building analogy as it is inaccurate when taken to extremes, in this context it is somewhat accurate.

You may have noticed a pattern in the blogosphere in that enterprise architects frequently ask software vendors to provide publicly available reference architectures using design patterns notation. Reference architectures are like codes while design patterns are like best practices. Note, that I am of the belief that best practices don't really exist and enterprise architecture is more like gardening. Here's why...



While I am a good software architect, a great infrastructure architect, a master in information security and a guru at software engineering, I am near perfection when it comes to enterprise architecture. Now that I have fulfilled my egotistical needs to pat myself on the back, I encourage you to check out this white paper by the Danish government on enterprise architecture.



Hopefully, you aren't employed by one of those enterprises that believe that all "technical" folks are somehow interchangable and don't acknowledge the unique contributions that each individual can bring to the table. If you happen to be employed by a boss who simply doesn't get it, suggest to them that maybe he should hire a maid service to do his next break job and see if he gets the message. Enterprise Architects should be considered as the Keepers of the Flame and help spread good practices to others, demonstrate Strong Technical Leadership and most importantly, enabling the strategic intent of the business...

Scott Mark in his blog outlined his 2006 Goals which are very close to my own. I guess great minds think alike...



I am not the only architect in corporate America that blogs. The world is priveleged that Scott also contributes his thoughts to the blogosphere on a frequent basis. Software vendors are well-served by adding him to their blogroll. There is probably something to be said if you are a software vendor and don't have a single customer on your blogroll. Anyway, this is a topic for another day. Like Scott, 2005 was a fantastic year for me professionally and personally and if God wills, this trend will continue. The following are some random thoughts and goals I have for 2006...

Architecture goals

• Relentless use of Agile methods - I have been an Agile zealot since its inception having operated with the same mental model but disconnected from others. The ability to delivering early and continuous value in the form of working software is vital to the success of enterprise architecture. Me and my peers will be savage in getting better at this.


• Use of non-hype Web 2.0 practices in the enterprise - Web 2.0 hype is still on the rise, so this will be a challenge. I have previously blogged that tagging is a key Web 2.0 concept that will be of use in enterprises. Folksonomy will become more important as folks in the ECM space will come to realize that taxonomy will never work in the long run. I also believe that increasing use of self-selected transparency will transform many existing one-way sites within enterprises.


• Developing people, not just IT solutions - there are key Agile principles around valuing the people in your organization. We did a better job improving talents and skills on our team last year than ever before, and will continue that practice. Investing in high-quality individuals pays the greatest dividend of any possible IT spend. The only hard part is in convincing others of this truth

Other professional goals

• Continue blogging - I have made some great connections through this blog, and it has been a great way to hone thinking on various topics. I have been pretty good in sharing my thoughts at least on a daily basis and sometimes more. I will attempt to do a better job in providing my reactions to questions left as comments.


• Presenting at multiple conferences - Last year I had the opportunity to serve on a panel at an academic-oriented conference. This year I hope to give a little more of my time to students interested in the IT profession and seek speaking gigs that realize this vision.


• Propose a lecture or training program to the University of West Indies - I will be proposing various topics that I could deliver to the Computer Science department as guest lectures or short training possibly in 2006 or 2007. I would do this on my own time and probably my own dime, as a means of giving back. I figured that it is in the best interest of all Americans to eschew outsourcing to India where money sent overseas doesn't get returned back to our own economy but does occur in both Trinidad and Costa Rica that we can support them in their ability to become outsourcing destinations of the future which of course starts with a good education system.


• Construction - In remodeling my basement to incorporate modern home automation, home theater and my data center, I learned an aweful lot about construction techniques and want to figure out how to make money off what I have learned.

Personal goals (that I'm willing to share!)

• Organize my charitable giving - our family has always supported various charities, but have not stuck to any one in particular consistently. One act is helps better align with this goal is listing some of the charities that I believe are worthy of your money in the left column of this blog. Hopefully you will consider making a sizable donation to them. This year we will be deciding on what goals and values to support, and what international areas to support and be more direct with support. I will continue to donate time, as this is often more valuable than money.


• Weightlifting - been on a quest to achieve the same strength I had when I was a school boy. For the most part, I have already achieved this goal in every excercise except the bench press. During my peak, I did a three-rep max of 400 pounds. I cannot even seem to get close to this. Have to figure out what I am doing wrong.


• Do a better job making sure my kids grow up multilingual - my family tree is pretty diverse and in order to show respect to it, I need to make sure that my two sons not only speak English but will also become conversational in Hindi and Arabic. They already for their age know some Spanish, primarily what they see on TV but the other languages are more of a struggle since they don't get the opportunity to be exposed to them on a daily basis.

Charlie Eakman is a 14-year-old young man in Pittsburgh with muscular dystrophy. This past week, thieves broke into his home and stole, among other things, all of his videogame consoles, games and movies. Charlie bought most of these with his own money, earned over the years from the $10 per 'A' his Aunt rewarded him with for his grades.

Please consider sending Charlie $20 so his can replace his games. After putting the check in the mail, reach into your pocket again and donate another $20 to the Muscular Dystrophy Assocation.

May God Bless You...

I figured I would take the opportunity to respond to a comment in a previous blog entry...



Listed below are the comments along with my own thoughts:

Vendors PAY analyst firms to be represented. It doesn't get much simpler than that.

Don't get it twisted. There is absolutely zero wrong with getting paid! If you have been paying attention to many of my blog entries, you may have noticed a theme. First, I have suggested to many CTOs that they should interact with some of the smaller industry analyst firms which of course results in not only software companies spending more money on industry analysis but also results in more folks getting paid.

What I am requesting though is just a little bit more transparency. In the financial world where the notion of analysts first got started is the simple fact that whenever they make a recommendation, they also disclose their holdings. For example, if you ever listened to Mad Money's Jim Cramer he always discloses whenever his recommendation to buy a stock is one that is already in his portfolio. Is there something wrong with a customer wanting to know if an analyst in recommending software companies whether that software firm is also a client?

Enterprise CTOs generally don't want to be 'first' at anything - the perceived risks are too high.

Perception and reality are always different. Do you think that many enterprises have purchased software because they believe their competitors are also looking into the same space? Do you think that first to purchase also equates to first to implement? Many of these same folks in the enterprise are truly doing first-mover things but just don't know it...

OSS doesn't present many monetizing opportunities for analysts

Hmmm. I disagree. Large analyst firms have figured out how to hold industry conferences on this topic. Likewise, small analyst firms such as RedMonk have figured out how to bring open source analysis to the marketplace while figuring out how to put food on the table. If you stated the problem space as some analyst firms haven't figured out how to make money on free software then you are onto something. Maybe the analyst firms that haven't figured out how to incorporate open source practices into their business models should become customers of the ones that have.

Analysts don't know what they know until the vendors tell them

Actually I believe that this is true and should be called out as such. If enterprises were to learn that real analysis doesn't really occur in many of the firms, what would they think? The real question though from my perspective is that this practice can be OK in some situations but what if architects in Fortune 500 enterprises whose business isn't technology (Duke Energy comes to mind) were to tell the story to analyst firms about the software they use or are intrigued by and their perceptions of it. This if anything would be of higher integrity since the folks at Duke Energy have nothing to sell and feedback can be considered more objective. Maybe analysts shouldn't collect all their information from vendors. Maybe enterprises haven't figured out that analysts not only supply you with reports but that you have a fidicuary duty to also supply them with information.

The real innovators don't follow the crowd - they do their own thing and jealously guard their IP. That's why you'll never find a detailed analysis of what Wal-Mart, Dell, Google etc actually do.

If a tree falls in a forest does it make a sound? Seriously, all large entities never keep their ideas a secret. Minimally, they file patents (which is a form of disclosure), release beta software to a limited demographic or engage venture capitalist firms to create startups that fulfill a particular purpose. The key though is whether WalMart, Google or Dell pick up the phone and call their industry analyst or whether analyst should instead not expect a phone call but listen to the conversations around them.

If an analyst wanted to know about whats going on with google, they could wait until the formerly scheduled analyst briefings and provide no form of unique insight to folks that subscribe to their work or they could savagely read the blog entries of all google employees and figure out the pattern of conversations that occur. Maybe it is good practice for industry analysts to also do the same in reading the blogs of their customers.

Is it true to say CTOs are influenced in their buying decisions by analysts or that branded analyst reports provide a comfort factor to buying decisions or support a pre-determined position? I suspect the latter.

Your reasoning hints towards the fact that having a pre-determined position is somehow evil. All humans have pre-determined positions on pretty much every issue in our daily lifes. I have my own thoughts on Peace in the Middle East, why enterprises should outsource to the Caribbean and why certain drugs should be legalized. The real thing is that analysis should bring compelling arguments that change the opinion for those that are either to the right or the left and this simply isn't happening.

Imagine what would happen if an analyst firm actually started publishing case studies of all the outsourcing firm failures vs only successes. Would clients become more informed? Would outsourcers gain insights into how to make their own offerings more compelling? Would enterprises crave more information on the topic and therefore increase their spend with analysts?

I am no longer alone in the blogosphere. Another architect from a Fortune enterprise with a wonderful first name has also joined. For industry analysts and software CTOs that cover the enterprise architecture, knowledge management and business rules space, you should add him to your blogroll.



The one thing that is almost never seen in the blogosphere is that one truly never gets to observe debate between two individuals who have more than professional respect for each other. You of course will see debates between industry CTOs that work for different software companies but never within their own company.

As individuals, I can tell you that we respect each other and that this is not given but earned. It is valued between both of us because we have open dialog both in public and private and we collectively believe that real honest insight emerges when two individuals have differing believes. In other words, success is in the mix.

For the most part, I will more than likely agree with his thinking but, don't be surprised if in the future I go on the attack. We grew up in towns that have had a long held rivalry (I am a Warhawk and he is a Warrior) and may at times appear to go back to these days. Blogging should be all about transparency and information sharing in a non-marketing department approved way. We have neither nothing to sell nor nothing to hide.



Imagine if industry analysts actually practiced pointing out discrepanies in each other's work? Do you think us customer would love to observe the dialog? Do you think our knowledge would grow even faster? The lack of meaningful dialog within the blogosphere is causing a knowledge crisis. We would be equally guilty if we participated in this commonly practiced form of insanity.

I can't wait for the day when an analyst from Radicati or Ovum in their blog points out why they believe open source analysis may not work, or if an analyst from ZapThink, Patricia Seybold or Yankee Group starts to ask for more pressing dialog from if software vendors start using the blogosphere to settle internal debates on product direction and allow the community to provide their own perspective...

Anyway, his blog is named Knowledge Crisis. Please check out not only his first couple of posts, but don't hesitate to leave comments. The blogosphere is a two-way dialog and I encourage you to engage in one with him...

Jeff Schneider has a contest going on that you should really check out. I hope to be one of the winners of the Tee Shirts he is giving away. Anyway, check out his blog entry for more details...

Yesterday, I had the opportunity to talk with an industry analyst for a large analyst firm regarding ServiceMix and some code I am planning on contributing. The conversation was frustrating and enlightening at the same time. It was frustrating in that I learned why analyst firms are struggling with telling the real story behind open source...



In knowing that many of my peers run around the halls of corporate America with analyst reports as if they provide insight tells me that if analysts are telling the right stories, that many enterprises are doomed to be mediocre when it comes to understanding the real value proposition behind open source. When it comes to open source, many of the analyst firms still think in terms of vendors and not products. The lack of a vendor makes it difficult for them to capture marketshare, brings the matrix and even makes it difficult to rewrite portions of information borrowed from the web site.

One example is that I cite often is the wonderful folks over at Duke Energy. For those interested in .NET development, they actively participate in the community and have contributed a rock solid application framework. How come zero point zero analyst firms have done a case study on them? In fact, how come zero point zero analyst firms have not even covered any Fortune enterprise that has created their own project? There are several out there and the world should know about them.

I guess if you look at the typical analyst report format, it would be interesting to see how much power generating capability they have. I wonder if analyst firms were to actually consider Duke Energy and list their revenue figures that the .NET framework they have made open source would then be viewed as a market leader?



One of the things that absolutely pushed a button was the perception that commercial products automatically have more users. The analyst quoted the number of customers each enterprise service bus vendor had. He then followed up with a statement that suggested that ServiceMix couldn't possibly have as many customers. Oh really?

Should open source projects start keeping track of who uses them? Should industry analysts instead of simply relying on vendor provided numbers do their own homework to figure out usage? Should industry analysts participate in the open source community themselves by joining listservs to see first-hand what the discussion is all about? Should industry analysts actually attempt to install the software themselves and build small proofs of concepts and not rely on Powerpoint for all their information?

For those that don't know, ServiceMix is a highly scalable Enterprise Service Bus that has more features and functionality than any commercial ESB on the planet! From my own participation and observation in this particular community, I am of the believe that it has about 800 viable customers which is more than any of the commercial offerings in this space today.

Another open source project worthy of attention in the enterprise is Liferay which has been certified by several third parties to be the most secure portal platform in existence and is the only one certified to run on 384 CPUs. The rest simply run out of steam if you attempted to throw say 10,000 concurrent users within a single instance.



If analysts want to count paid customers, then I can honestly say that both Liferay and ServiceMix will shortly have over 5,000 paying customers. I have asked everyone in my second home of Biche Trinidad to pay exactly $1 TT to each of these projects. Of course, knowing both of the leads of these two projects they will more than likely donate all proceeds to a worthy charity...

It is simply a crime for enterprises to blindly follow research reports when they don't contain the entire picture. Enterprises need to demand of every analyst they talk with that both commercial and non-commercial open source projects are listed next to proprietary closed source vendor offerings. Putting them into separate reports is also unacceptable. I wonder if Stephen O'Grady of the high quality industry analyst firm Redmonk wouldn't mind putting together a list of ten things that enterprises should consider when purchasing analyst research? The continuing crime spree committed by most analyst firms needs to be halted immediately.



Over the past several weeks, I have noticed a pattern in that multiple industry CTOs had posted in their blog disappointment whenever they have participated in an enterprise bakeoff. While not having any insight into the reasons they lost I do wonder if they have actually figured out what their real job is? So many industry CTOs feel it is their job to ensure conceptual integrity to the product line. While this is important, there are tons of other things that are more important.

If you understand that folks within the enterprise obtain their "wisdom" through one of two channels then you would realize what your next action items are. If you know that folks in the enterprise achieve information via the industry analyst channel and you also know that analyst firms aren't of the right mindset and you are taking steps on a daily basis to change their communications, well...

Likewise, if you understand that google is also a research tool and that by engaging in dialogs with the community that also happen to get indexed by a variety of search engines, you may be hyperlinked and come up higher than those who don't. Maybe you should spend time reading tomes such as the Cluetrain Manifesto. After all, hyperlinks subvert hierarchy...

Maybe you may conclude that the industry analyst model is fundamentally busted. Maybe you may noodle ideas on how not to sit on the sideline but instead embrace the notion of Open Source Analysis. If the model is busted for you then you should rightfully assume it is also busted for your customers.

There are lots of analysts with integrity. I consider Jon Udell of Infoworld one of them. He too at times needs a course correction in that he is equally guilty of not testing non-commercial open source projects side-by-side closed-source proprietary product offerings in the Infoworld Test labs. Hopefully he will fix this in upcoming issues.



Maybe what customers really need is for vendors to figure out how to work with competitors so that real industry reference architectures emerge. I know that many of my peers would be filled with tears of joy if they could see one in the rules engine, BPM, ESB, and Identity Mangement space?

Maybe if analysts simply provided answers that customers ask in their blogs. I wonder how many analysts or even CTOs can provide insight into Enterprise Content Management or even thoughts on BPEL and ESB and what folks should be really considering? Maybe analysts and CTOs don't really care. Maybe they are comfortable with mediocrity...

Every role within the enterprise, comes with both rights and responsibilities...



Enterprise Architects' have the responsibility to:

• Understand why you are doing enterprise architecture in the first place. It is not to create comprehensive documentation, fill out Zachman frameworks, achieve higher levels of CMM, etc but to enable the strategic intent of the business that employs you. You must understand why whatever you are promoting is needed and why it is your customer's priority.


• Produce high quality work even when you are pressed to do otherwise. Low quality output benefits no one in the long run.


• Mentor others, provide stewardship for ideas conceived by others and impart whatever skills and wisdom you may have.


• Make sure that your recommendations and estimates are thoughtful, complete, ethical and as accurate as possible. Don't just reflect ideals, you must reflect reality.


• You have the responsibility of not doing just your part, but work with others and insure the success of everything under your stewardship.


• And most importantly, accept the consequences of your actions...

I was searching for something on my PC and ran across a file I had saved awhile back. The file essentially outlines how enterprises believe that "process" can make up for the lack of talent. In order to prove the point, the contents of the file outlined how to create a methodology for running the 100m.

• Step 1: write about running really fast.


• Step 2: Go and draw a plan of the racetrack.


• Step 3: Go and buy really tight lycra shorts. NOTE: I hope none of my coworkers are reading this blog. The thought of them thinking about how I look in tight lycra shorts..


• Step 4: run really, really, really fast.


• Step 5: cross line first!

It's that step 4 that's the tough one. But if you put lots of emphasis on 1,2,3 and 5 it's possible no-one will notice and then you could probably make a lot of money selling the methodology to would be athletes who think there's some "secret" to being a 100m runner over and above being born with the ability to run fast.

Unfortunately, the outcome of methodologies when applied to project management, software development and enterprise architecture is that you end up with extremely well documented TERRIBLE designs. Unless you hire, recognize and retain real talent you are doomed from the start. If you are one of the few enterprises that have figured this out, the architects would have come up with a good designs anyway, but on less paper.

I hope the analyst firms and consultants who push process and methodology won't be too upset about this perspective...

Yesterday, I ran across a highly respected architect (Hi MW) where we chatted about our history in IT. He described an antipattern for which I didn't at first know if there was a name to it, but figured I would share it. I am of the belief that this is actually practiced even more than Management by Magazine. Herein, we will refer to this newly discovered practice as: decisioning via email...



Here is how the discussion goes. Someone sends an email comparing product/solution/recommendation/etc A to product/solution/recommendation/etc B to a large distribution list. One individual in the distribution list actually reads the email in full detail and attempts to rationalize why product/solution/recommendation/etc B isn't a great fit and ultimately states that it doesn't handle X.

Here is where the pattern emerges. Someone will assume that since product/solution/recommendation/etc B doesn't handle X then by implication product/solution/recommendation/etc A must also suffer from the same deficiency. Folks who are logical understand that the only statement is that B is deficient because of X and not A.



The blogosphere is actually a bigger distribution list than any email system and suffers from the same fate. On countless occasions, folks who have read my blog assume that if I posted an amusing picture of George Bush doing something idiotic that I must somehow be a democratic. It never enters their mind that regardless of political affiliation that George Bush is still an idiot!

For the record, I am neither Democratic nor Republican as their is a dime's worth of difference between the two parties. I believe that America truly needs a third party with totally different set of values than either party brings. We shouldn't be forced to choose between the lesser of two evils to either run our government nor adopt a product within our enterprise.

Likewise this same argument can occur based on the phrase buy vs. build. How about introducing a third notion called open. Buy is evil because you have to pay 100% of the money and lose all control only to watch your competition have the same solution that you have when in all reality, you were of the believe that Rationalization is a form of architecture and justified spending lots of money on buying commodity products for competitive advantage.



Likewise, build is evil in that reinventing the wheel for the most part within your own enterprise will increase the total cost of ownership in the long run and in all honesty, you don't have Strong Technical Leadership to pull off something truly wonderful and are cursed with mediocrity for eternity.

There is always a third option. It is called open source. An enterprise should take every problem space and decompose a problem into determining which aspects of the problem are commodity and which aspects are competitive advantage. For the commodity part, you don't have to build 100% of it yourself nor buy. Consider finding other enterprises who have the same commodity needs and approach them regarding building this aspect. If you can find one other enterprise, then maybe you only need to build 50%. Find two and the amount needed to be built becomes 33% and the trend continues.

NOTE: Folks would be well-served by looking at models done by the airline and auto industry in this regard. Would be great if some of the larger analyst firms started to talk about how enterprises can directly build open source themselves...



Likewise another pattern that I often run into is that folks think that I am somehow blogging about work. Nothing could be further from the truth. I blog about things that I think about on a daily basis. If you are reading my blog, you should understand that anything I say is applicable to any company I may work for and never has anything to do with my current employer. Blogging about work and our secrets would be just plain dumb. If you read into my blogs then you will be even dumber.

The point of today's blog is pay attention to the words, don't read into what people are saying and sticking only reading what they have said. If you aren't capable of logic, then stay home and don't read at all.Anyway, I have to figure out how this pattern may be related to The Five Rules of Propaganda. Anyway, if you are into conspiracy theories, check out this blog...