Enterprise Architecture: From Incite comes Insight...

Stephanie Overby of CIO Magazine in the latest issue covered the topic of recruiting top talent but of course left out some important considerations...



The biggest gripe with the article is that she of course never talked about the characteristics of strong technical leadership. Would top talent want to work for traditional IT management that is busy aligning itself with the business or those truly doing something special?

If I had to choose my next IT executive I would want to work for it would be a toss up between Roger Carter of Fedex or Phil Venebales of Goldman Sachs. Do you think that I would choose them for their business savvy or that they are technical and represent qualities I aspire to?

Another dimension that never seems to be discussed is not just the CIO and their background but those who report to them. If the background of all of their direct reports doesn't reflect the characteristics that I desire, then why should I pursue? If there were an enterprise where all the IT management were from project management and business backgrounds while another had those characteristics but one of the IT leaders came up through the architecture ranks, which organization do you think would be more attractive to talent?

The phone has rang four times this week with recruiters from others within my own vertical pitching their value proposition. The funny thing is that none of them had any real reason why I should consider a change? Competitive salary equates to I will be making about the same as I do today. None provided me with a chance to leverage my strengths when it comes to thought leadership, open source or other things I am interested in pursuing while most wanted to cripple me with their competency models.

Another characteristic not discussed has to do with industry verticals. If my employer told me to study for my Series 7 to get a promotion, I would be all over it. CIOs haven't yet acknowledged that while business acumen is important, some businesses are simply about as interesting as watching paint dry.

Stephanie did however note that contribution back to the community is vital and encouraged IT management to start getting involved with local high school and college students not for just recruiting but to spark an interest in IT. Guess I will have to highlight this and put it on a lot of folks desks in the AM.

She also hinted at training but didn't indicate any metrics around what the most mature enterprises are doing. My informal research indicates that top enterprises ensure that their staff gets a solid two weeks of training each and every year while laggards get the bare minimal if anything.

Suprisingly, she didn't get a quote from an industry analyst. I wish she had talked with Brenda Michelson of Elemental Links before publication...

A peer had asked me my opinion on which enterprise architecture tools we should consider and I didn't have an answer. I figured I would gain insight from the blogosphere as to what I should be noodling here...



Let me start off by saying that this is not an opportunity for a vendor to blow up my phone with a thinly veiled sales pitch on all of the wonderful tools they may sell.

I have always been of the school of thought that one should focus in on people, then process then tools in that order. This probably results in me never thinking about wonderful productecture and the assistance that software vendors provide in doing Powerpoint demos to large audiences.

Some enterprises are focusing in on this notion of ERP4IT. Charles Betz frequently discusses tools that help IT run as a business. He has a philosophy that is interesting at some level and talks about ITIL, COBIT, Six Sigma and how they converge with EA.

Other architects in the blogosphere have taken a different approach. Robert McIllree and others talk more about repositories for storing enterprise models. Having a view of what all the systems do helps enable business architecture. Others still seem to pursue more content management approaches with stronger typed taxonomies that help folks find stuff that is already documented and to counter the trend of simply storing stuff in folders in Sharepoint or on a file share that no one can ever seem to find.

There are probably more dimensions that I haven't thought about. I would love to know from my fellow EA peers, what tools are they currently using, the rationale for using them and most importantly is the effort expended in implementing them worth it.

For the record, in thinking about it I would also want to know why an EA would need any tool beyond Powerpoint,Visio and a Wiki?

In the short two days this week, my phone rang a total of twenty-six times with a stupid sales person on the other end attempting to pitch their so-called value proposition...



There is a formula to the pitch, the dog and pony show. Everyone has been indoctrinated into thinking their product somehow has features that we must absolutely consider. If this was the case, why aren't they apparent to us folks on the other end?

If there were one think that would increase the productivity of enterprise architecture teams, it would be the banning of sales folks from software vendor companies calling us about their issues. Imagine if enterprises figured out that they should only take calls from software vendors, say the last Friday of every month, would productivity go up?

An even bigger drain on productivity is win these clowns start calling my peers. What of course happens is that my peers want me to be successful and either forward along information in an email which helps exceed my inbox quota and I can't get done communication that needs to occur before this gets moved to the deleted items or they will want to engage me in a conversation about what they have heard. I don't mind talking with my peers about cool things but in all reality it is somewhat painful to have the same conversation mulitiple times.

Maybe I should task the vendors on how not to bother me so that I can focus on the real problem at hand. One technique that I use which is both good and evil is that I have started asking five questions in which not a single sales person ever seems to know the answer to. They are:

• I understand you can probably produce research briefs from large analyst firms. Could you tell me when was the last time you briefed industry analyst firms such as Redmonk, The Burton Group, Nemertes, etc


• Please send me the URL to the blog of your CTO


• Could you tell me not what open source projects your product contains, but which ones your company contributes to


• I will be attending the following future conferences x,y,z. Will you have a booth there? I can only pay proper attention to things when I am not in the office


• Have you talked with Jon Udell of Infoworld? Do you know when your product will be in their test labs?

Anyway, I have decided to re-double my efforts within my own enterprise to start evangelizing open source and will do so not because of cost or even quality of solution but so that I don't have to be irritated by sales people and the frustration they bring...

Public, private, and civil leaders should confront together the problems that none can solve alone.



"Leaders everywhere no longer express as much confidence about the future as they once did. When they speak candidly, it often sounds as if they feel trapped in quicksand, unable to move forward easily. The methods and tools that helped them succeed in the past no longer work."

The root cause of the challenges confronting these leaders is complexity: the growing density of linkages among people, organizations, and issues all across the world. Because people communicate so easily across national and organizational boundaries, the conventional managerial decision-making style — in which a boss exercises decision rights or delegates them to subordinates — is no longer adequate.

For more insight into open sourcing problems of the enterprise, check out the Megacommunity Manifesto by thought leaders at Booz Allen Hamilton...

Figured I would share an interesting conversation I had yesterday with two fellow architects...



The funny thing about most corporations is that many of them have top talent that is heavily underutilized. For example, if I were to look across the street towards one Fortune 100 enterprise, I could find the father of one of the first object-oriented languages, if I were to get in my car and drive about four miles, I could meet the father of case tools, if I were to walk down the street I could run across the father of what is one of the first firewalls. The funny thing is that all of these folks whenever I run across them tell me that time at work is sometimes spent on outside interests.

Talent management nowadays seems geared towards leveraging average folks within the enterprise with the hopes of getting some productivity gains out of them. I haven't ran across a single executive that knew what to do with stars. Part of the problem that many executives avoid that causes the underutilization of top talent is the crutch of communication. Whenever magazines, industry analysts or top IT executives speak to the communications problem, what they are really saying is that they have a problem with getting average folks to buy-in. Top talent doesn't have a buy-in problem because they are usually the ones where shift happens.

Several of my peers joke that if say the Aetna, Cigna or Mass Mutual hired top talent that the very first thing they would do is beating them into submission and make them average. If they hired say James Gosling, instead of leveraging his expertise in Java, they would make him give presentations to CIO types on the value of generics. Likewise, if they hired Martin Fowler, they tell him that agile stuff is nice, but they really need for him to work on creating metrics for governance purposes. If they hired Grady Booch, they would assign him to quality assurance for India offshore development and possibly have him do code review of folks who only had one years of coding experience.

Talent management hasn't yet been discussed in the analyst community and its relationship to communication. The enterprise that has mature talent management practices acknowledges that communication not only is not the problem but that they should instead optimize show that communication is reduced.

A wise architect and I were debating that communication within the enterprise is NP-complete or just exponential. When an IT executive asks their team to increase communication, they of course don't want to lose productivity while doing so. So, if on day one, an architect needs to communicate to say ten people and then the enterprise goes through a reorg and tomorrow he/she is forced to communicate to one-hundred people is this sustainable? The real problem with communication isn't about volume but ensuring that one can communicate with only the right people while weeding out those who don't need to know, who will get it twisted or will simply defer until they know. With constant reorgs, changes in IT management, and expectations that communications can get significantly better (only marginal improvement is possible) the problem space of talent management and communication is NP-complete...

Figured that for those who follow, they hopefully won't make the same mistakes I have..



An architect, whom I have grown to respect said something intriguing to me in hopes of cheering me up and bringing me out of my feeling of being burnt out. He said James, you are one of the most credible architects in the entire company. He went on and elaborated that I am credible because I not only acknowledge my limitations but I openly declare them. Transparency breeds credibility. An architect can trust me because they know I will tell them exactly what I know and what I don't. I never pretend to represent an agenda and give suboptimal information simply because of my role. I want to be successful and more importantly want others to be successful.

Saying I don't know gains credibility amongst the technical ranks but has otherwise hurt my career as those ladder climbers from above have throughout their career said they know when they really don't. I recently had a conversation with noted industry analyst Brenda Michelson regarding the notion of talent management within IT. Hopefully, I can persuade her as she does case studies on other Fortune enterprises to ask IT executives if they permit folks to be transparent in terms of their strengths and weaknesses. Maybe, she should take it beyond inquiry of just permitting but see which enterprises actually encourage it.

I also had a conversation last week with Lyn Robinson of the Burton Group regarding the notion of EA maturity models. I am of the belief that to reach the highest levels of maturity, transparency is not just something that happens but is actively encouraged top-down.

Many folks may know that I rarely watch TV. I don't have cable nor satellite. When I do watch TV, it is only PBS. I suspect many of the top executives watch Survivor, where they learn tactics of being passive/aggressive to fit the moodswing of the minute. It is interesting how at one moment, the folks on Survivor are the best of buddies and at the next, they are backstabbing each other. See what watching too much TV does to IT executives?

In the meantime, I guess I should spend some time this week noodling whether I want to accelerate my career and get to the next tier by being less transparent or whether my personal integrity is for sale at any price...

Anytime you hear an IT executive or industry analyst talking about communication problems in the enterprise, kidnap that fool...



The mention of communications or the lack of has received more industry analyst and media attention than it deserves. For the record, there is not a single enterprise on the planet that has a communications problem! There problem resides elsewhere.

Have you ever heard of something called open source? Thousands of developers work on projects such as GNU Linux, Apache, Liferay and other projects who not only don't have problems communicating but never have ever met face to face. Some of the projects I contribute to are wildly successful and yet the spec lead may have never even heard my voice nor know even what I look like.

Maybe if enterprises had real leadership, they may figure out that they should not focus in on better ways to communicate but instead figure out ways to reduce the need to communicate. If your competitors internal IT process requires communicating to ten people where your equivalent internal IT project requires fifty, guess who has the competitive advantage?

Have executives ever thought for a moment that maybe communication is improved by doing organization chart optimization? Would communication improve if everyone wasn't matrixed (dotted line) to ten different bosses but only had say one? Maybe communication would be improved if you figured out as IT executives how to instill trust in your employees? What if you trusted folks to do the right thing and made it easy for them to communicate with you when things go wrong?

I have managed to stump both industry analysts and thought leaders in the XACML space by asking them one simple question...



At work, we are doing a POC with several vendors in the entitlements space and XACML is a key component in their approach. We spent a week explaining our model in terms of narrative and it still hasn't fully been digested. When asked how others communicate their authorization models in terms of pictures, no answer emerged.

It seems as if everyone can describe it in terms of a conversation but no one has ever figured out exactly how to draw a real-world authorization model with all of its complexities in a single diagram.

I searched google where the conversation seems to be on process and methodology but not architecture. Likewise, there are many models for how vendors should design their products but nothing of use to the enterprise. Even in reading the methodology stuff, guys such as Sena Systems always assume forward engineering via use-cases. What if an enterprise already has a model? How do vendors methodologies in this space handle reverse engineering?

Of course we can find blockatecture, data flow, and infrastructure level views but none of these tell how our authorization model actually works. Figured that I would ask the blogosphere for assistance in helping me identify how to draw a single diagram in this space.

Thoughts?

So what does a bad day for an enterprise architect feel like?



In today's business climate, IT is no longer fun. Gone are the days when folks used to have genuine conversations with each other. We are in the Dilbert zone of IT governance where many IT organizations lack strong technical leadership and make it painful for those who are sincere in their intent. The inmates are running the asylum.

Yesterday, was one of the worst days professionally in my life. Normally, I have had bad days but whatever went wrong, there always seemed to be an end in sight. Sadly, while I know there is an end sooner or later, the inability to see it is depressing. In talking with a well respected peer, he gave me advice that made me think deeply about my career.

One peer pointed out to me one of my strengths which is also one of my weaknesses. When it comes to paradigm shifting, I tend not to struggle. We ended up having a conversation on blogging where he was attempting to gain insight into what did I think about before I started to blog in hopes of learning how to help others paradigm shift. Sadly, I remember the day that I got interested in blogging. I was reading a blog entry by Doc Searls followed up with another blog entry by Stallman and another by Rageboy that touched me. I remember my wife calling me for dinner and not thinking about it anymore. The very next day, I thought that I too could share valuable insight on my own world with others. I guess I didn't paradigm shift and simply just starting doing it.

Another peer asked me about insights into contributing to open source. At the time, I was working on a project to prove out something with portals and got frustrated with closed source vendors blowing up my phone which caused me to look at open source projects where I ran across Liferay. I downloaded it. It worked. I wanted it to do something with Single Signon. I coded a sample but knew I had zero interest in maintaining long term and therefore contributed it. No noble thoughts, no paradigm shifting. I simply did it because it makes sense. Shift happens.

Yet another well respected peer also provided me with a perspective of success in enterprises. Success is not based on doing something on-time, on-budget and with integrity. Success is based on taking an idea regardless of whether it is brilliant or utterly stupid and getting others to do something. He suggested that I am actually more successful than I realize and noted that as one moves up the ladder and works on things that are more strategic that seeing the results of one's efforts takes a lot longer. I must be truly important to the strategy of my enterprise as I haven't seen the results of my efforts in a long while.

Gone are the days of immediate gratification. Maybe this is the reason I have taken up an interest in home improvement. If I envision something, go to Home Depot to get the materials, come home and build it I can reflect on not only the journey, what I did right (and wrong) but also know exactly what I have accomplished.

Yesterday, more so than any other day, I felt lost in the wilderness. It is easy to head to a destination if you know where you are. Today's enterprises are managing to take away the ability for anyone to have a bearing point. Maybe I should ask my boss to provide additional clarity by force ranking me with others and further obscuring whom I am being compared to because it is HR confidential.

The saddest part of the day, was in sitting at my desk envisioning the creation of yet another thinly veiled chock-a-block Powerpoint presentation that lacked substance only in the fact that I wasn't throwing daggers at others but creating it myself when I ended up zoning for a couple of minutes while looking at my favorite IDE (Microsoft Outlook) and noticing that the day said August 24th. It was 3:30 pm when I realized that today was my birthday and I didn't even know it. The feeling of losing oneself is not good.

I guess it doesn't surprise me that I forgot my own birthday as I never really ever celebrated it. I have always thought of my own birthday as a form of ceremony reminiscent of some of the things done in corporate America that don't really matter in the grand scheme of things. I haven't yet figured out if forgetting is worse than remembering.

Anyway, we all have our vices. For some it is drugs and/or alcohol, for others it is sex or money. For me, it is none of these things. I guess my vice is doing meaningful things with integrity. Modern day enterprise architecture requires sometimes selling one's soul. Of course, there are plenty that can rationalize anything including changing the definition of what it means to be successful, but we know that rationalization is a trap. Maybe it is bad day because I am experiencing withdrawal from my drug...

I am one of the biggest advocates of Liferay Enterprise
Portal in Corporate America. Recently, I have been spending time with EJBCA which is a 100% open source certificate authority platform built on J2EE. For enterprises that need to establish an internal PKI infrastructure, this is more than worthy of attention from enterprise architects.

I have found that any time I blog on the evils of outsourcing, folks from India come out of the woodwork. Hopefully, instead of throwing daggers, I may persuade one or two of them to consider joining both Liferay and EJBCA as both projects are in need of additional language support. If you can write Arabic (I can speak but not yet write), Tamil, Hindi, Tagalog, Farsi, Hebrew or Portuguese, they could use your assistance.

Maybe developers from Wipro, Cognizant, Infosys or even Accenture would volunteer a couple of hours to help in this goal? Likewise, if you happen to have knowledge of the Spring Framework and wouldn't mind contributing time such that EJBCA can work without EJBs, then you will definetely be doing the world a great service...

The vast majority of large enterprises have IT budgets that are growing faster than their business. Maybe the problem resides not in outsourcing, project management or any other second class concern but is an indicator of the lack of strong technical leadership...



We wouldn't hire a doctor no matter what his credentials were to run a large police department any more than we would hire Johnny Knoxville to run the Federal Government simply because he has the ability to influence others. IT can describe an organizational structure or it can describe a discipline. This leads to the conclusion that just because you work in an IT organization, doesn't make you an IT professional.

Enterprises that acknowledge the distinction between IT the organization and IT the profession tend to have more successful cultures that grow and thrive and most importantly don't have obscene costs that business folks rant about. Successful enterprises have strong technical leadership and the culture that encourages even more of them to be created.

Culture is the manifestation of growth and wherever you find growth you can also impute leadership (either as literally leading edges of a growing organism, or as the motivation behind growth). In enterprises that have strong technical leadership, the recognition of the importance of IT exists not just because the leader happens to be technical, but because of the value it brings to others.

Many organization features the typical structure of employees reporting to managers reporting to executives. Poison in that environment is mistreatment of people causing low morale, high turnover, poor quality - in other words, poor culture - which causes poor performance as in failure to meet business objectives or seize opportunities. If the leader has walked in the shoes of those below him, mistreatment is less likely to occur.

The funny observation is that a pattern exists amongst most good enterprise architects in that they tend to suck at management but are great leaders. Leaders often emerge when problems arise. Often you will find a lowly architect taking charge of the team when management above is sick. Even though the gallant architect has no authoritative power, he has effective power because people will listen to them when they will not listen to their management. Leaders are the one with the real power. And of course they affect culture. They're the ones with the power to do so.

Enterprise architects need to have an agenda where people come first and the first order of change is culture. Remember, people, then process, then tools in that order...

Yesterday, I went to the school I attended when I was five years old for an open house. One of my sons is starting kindergarten next week, I suspect I will have to work very hard to make sure that he doesn't value much of the crap taught in today's school systems...



He will be attending the same school I did and I was happy to learn that he will actually have the same gym teacher who keeps it real. They still play dodgeball, kickball, have races where there are winners and more importantly there are losers. Some school systems don't want to shock kids into thinking that they are losers but reality dictates otherwise. In corporate America, I can say that even though I am wildly successful, I tend to lose more often in my day job rather than win. Of course, if you practice management by magazine or read any of the Covey garbage, I didn't really lose and created a win-win for both parties, but I refuse to inhale.

In school you are taught that working successfully alone is a reward as working in a team setting is cheating. Likewise sharing information with other people or even building upon the work of others is plaigarism. In school, effort is rewarded more highly than achievement which if were ever true in corporate America, I would be King of IT and all the IT executives would be working for me.

Over time schools help gas kids heads up in convincing them that they are very intelligent when reality dictates that only my two sons are (snuck this in to see if you are paying attention). Under the guise of confidence building this does help when competing on a local scale but reality dictates that if you think you are smarter than your work peers then you have a bigger problem.

The biggest bullshit thing that occurs in school systems is that they teach you for any problem, there is exactly only one correct solution and that there is someone in authority that can tell you what it is. Most folks in corporate America in authority acknowledge that they don't know the answer and that there is no one way to do things.

Actually, the real biggest bullshit thing that serves as form of indoctrination is that you will be promoted every year unless you are doing very poorly. I haven't yet gotten promoted to the next tier at work. Maybe I should walk into my bosses office and demand a promotion?

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.

It is important for enterprises who realize that IT is key to realizing their strategic intent that all impediments to freedom of movement be removed. If an enterprise is constrained by third parties yet their competitors who practice open source development practices are not, guess who has real competitive advantage...

Many industry analysts have been notoriously silent on how DRM harms enterprises. Organizations such as Defective by Design understand that electronic freedoms and privacy are more important than the ability to cripple software. Many enterprises have procurement clauses that prevent disabling features yet haven't taken the step to ensure that their own customers and partners enjoy the same freedoms.

Likewise, DRM also harms our educational system and puts America at a competitive disadvantage. Have you seen the letter to the Boston Public Library? If there were ever an important topic that credible industry analysts such as James Governor of redmonk should blog about, this would be it...

I will be speaking at the upcoming Techforum in New York City on October 19th on a variety of security topics. Hopefully folks who read my blog will be in attendance...



Folks such as Gary McGraw have talked enough about the notion of writing secure code but this simply hasn't been on the radar of most enterprises nor many software vendors for that matter. While open source projects such as Liferay Enterprise Portal, ServiceMix and JBoss have been independently validated to be more secure than their closed source counterparts, industry analysts never seem to think that security is an important consideration in terms of their placing closed source vendors into leaders positions.

Maybe the real problem is that folks need to change the conversation and ask is there ever going to be sufficient economic incentive to write secure code? We know out of the gate that the current model of industy analysis simply won't help the enterprise become more secure as validation would require industry analysts to actually install the software vs simply listening to conversations.

Some folks are of the belief that insecure software is caused by economic reasons of which I disagree. Of course vendors make it a priority to add new features to each release of software while not necessarily fixing defects that were introduced in previous releases. One can acknowledge that there is an economic incentive to put features over security.

I am of the school of thought that the quality of software or lack of is not a matter of economics but is a matter of knowledge. If one could build security in vs making it an after thought, the average software vendor could do both at the same time with no increase in cost.

Someone within a large enterprise recently commented how they would love to work for Microsoft as they are sick and tired of working with folks who simply don't know how to code. There is something to be said for Microsoft in that they have folks such as Michael Howards whose job it is to help others write more secure code. What Michael is working on should be a discipline that makes it to corporate America as the exposures to leakage of personally identifiable data are even higher.

Unlike at Microsoft, most corporations will allow folks to walk in from the street or even telecommute from countries such as India without even knowing how well they actually code. They can rationalize (rationalization is a trap) in that they look for years of experience but never ask the question of does this person have five years of experience or did they have one year of experience five times.

It would be intriguing if enterprise information protection programs could be empowered by creating corporate policy to stop the creation of insecure code within enterprises that would extend to things they also procure. This is the only thing that would change the game. Of course, those enterprises who have IT executives who lack strong technical leadership upon learning that their competitors are ahead of them in this regard will practice management by magazine and think they could throw money at the problem and get it all twisted.

Economic incentives simply won't work in helping produce secure software. If you don't know how to do the job better, more money won't help. If you know how to develop better software, it will be cheaper, both in the long and the short term, to develop higher quality software than lower quality software. I wonder if IT executives will start respecting the role of software developers and start getting them some real training...

Last week, industry analyst Brenda Michelson to conduct research for a case study she is doing on enterprise architecture practices. I figured I would share some of my thoughts regarding her visit...



I happen to work for one of the most open large enterprises on the planet where we frequently provide updates to industry analysts in terms of our practices. Being that I had the opportunity to put together the agenda, I made sure it had a good mix of folks throughout our enterprise. Of course, she had the opportunity to speak with our SVP, but more importantly she also got a chance to speak to folks who were new to the discipline of enterprise architecture and all of the folks in between. I hope that she is of the belief that my peers upon meeting them were thoughtful and more importantly transparent in terms of them sharing.

After the visit, Brenda dropped me a note indicating that she wanted to have a followup conversation with our most junior architect. I sent her an email and told her I would have to blog this as this isn't typical analyst behavior. Having brought in analysts from large firms in the past (For some reason I haven't talked with IDC yet) they all tend to want more time with our executives and ignore junior folks who actually are sincere in their interactions. Brenda didn't make think of anyone in the snobbery way that some analyst firms treat folks in the middle of the pack. She gets one check for knowing how to get business out of us.

Anyway, it did remind me of something that has been bothering me. Afterwards we did have a chat about the folks over at Redmonk whom I have the utmost respect for. Lately, I have been growing increasingly frustrated though in that I would like to see the relationship grow between Redmonk and other large enterprises. I acknowledge that the Redmonk style isn't condusive to the dinosaur thinking that most IT executives practice but am of the belief that there needs to be a sense of urgency in getting them engaged in other conversations.

I was thinking that the best way to solve for my own concerns would be to publicly invite them to meet our coworkers face-to-face without this over the phone stuff that is done by other analysts firms to do a case study on any topic that is within my authority to give permission to. If James, Steven and Michael are ever back in CT visiting IBM and want to drop by and start on a case study, then I am here to help.

Brenda can testify that we are pretty easy to work with and have few constraints on what can be discussed. The only problem I think we would have to solve for is our desire for formal research reports over blogs. Redmonk's work on compliance oriented architectures was thoughtful and consumed by many. The main problem though is I don't want them to be a one hit wonder. Sometimes advice to those whom you respect is tough yet I believe that they have something to offer that others lack.

The only other thing is that as Scott Mark mentions is my frequent use of my blog as the bully pulpit. I would of course after doing analysis on my peers that Redmonk also do a case study on Scott Mark's organization for all to consume. For those who are clients of Forrester, Alex Cullen just completed a study on our EA approach. You should read it...

Hand waving is a metaphor for avoiding communication...



Many IT folks do hand waving under the following situations:

• They don't really understand the subject area but have to represent it


• The explanation is complex and there isn't enough time for folks to truly understand it


• They are presenting to folks who really don't care


• They are evil and attempting to cover their deeds

Of course, IT folks who do hand waving sometimes also use comic diversion once their arms get tired. I previously mentioned that I will be speaking at the Tech Forum in NYC. Maybe I should count how many presenters do hand waving. I am of the belief that there is a high correlation of hand wavers to those who also in their presentations bombard their audience with facts and references created by large industry analyst firms.

one of the main goals of both enterprise archictecture and software engineering is to make software easier to change. However, if we all see change differently, it is hard to agree on the best practices to achieve this goal...



There is a fine distinction between making things appear different (IT/Business Alignment comes to mind) vs having done something that makes things happen differently (e.g. federated identity). Many enterprise architects are good at perceiving something has changed but don't really understand what, how, why and when it did.

Maybe we should distinquish between perceptions of general patterns of change, and perceptions of a given change. The second is more objective because it is a particular something that can be directly analyzed. The second also involves a mental summary of past changes endured and using those to estimate (distinct from predict) the pattern of future changes.

If we were to adopt pattern-oriented ways of framing EA problem spaces we would uncover many insights. We may realize that the practice of documenting current state on strategic initiatives may not be of much value. Likewise, documenting the way things change on top of this under the guise of making things clearer is somewhat analogous to gambling.

Reality states there is no long-term pattern to change. Short term patterns are often dictated by the current mangagement of a given company or the nature of the current market. There is more benefits in going after these kinds of changes.

Here are some links to the results of some interesting surveys...



results for survey on Enterprise Architecture and Software Development
results for survey on Outsourcing
results for survey on Peace in the Middle East
results for survey on Thoughts on duckdown.blogspot.com

I wonder if James Robertson would use the results to prove out that Smalltalk is superior to Ruby on Rails...

In The Periodic Table, Primo Levi tells a story that happened when he was working in a varnish factory. He was a chemist, and he was fascinated by the fact that the varnish recipe included a raw onion. What could it be for? No one knew; it was just part of the recipe. So he investigated, and eventually discovered that they had started throwing the onion in years ago to test the temperature of the varnish: if it was hot enough, the onion would fry.



It is funny how enterprise architecture disciplines seem to only focus in on new stuff where the better focus may be on finding places where we throw onions into vats. Some great places to look are within many of the time-honored governance processes that seem to be more and more pervasively implemented within modern enterprises. The notion of best practices seems to be uttered out of many IT executives without regard for whether they still make sense.

For example, the notion of representation and buy-in is all important. There are many articles stating that IT breaks down do to the lack of communication and therefore suggests that EAs should communicate even more. Nothing could be further from the truth. How come no one ever suggests creating an organization structure where the average person would only have to communicate to two groups instead of sixteen?

At least we are moving somewhat away from the control the message culture of the 90s but have also went overboard with this. Sometimes we have to send out documents before their time. Sometimes, documents get circulated before even spell checking has occured? Some folks feel good that they are sharing and in all honesty many of the folks we send documents to won't read them anyway.

So what is the benefit? We managed to kill our internal email systems and consume more storage (NOTE: Buy stock in EMC) than what makes sense. By circulating documents before their time, we make those who actually read things become distracted and turn their focus to errors on the page instead of getting them to focus on issues that actually matter.

A best practice is a rule in disguise. What happens if a rule was put in place to solve a specific problem? What if that problem still exists, and following the rule still solves the problem? When you point out the expense of following the rule, people can get scared, fearing that they won't be able to solve the original problem without adhering to the old rule.

Maybe we should eliminate all so-called best practices and then attempt to implement our proposed solution. When the old problem comes back then we can then return to the best practices and create a new document to explain why this practice was in place originally instead of just following it blindly. I wonder if our corporate thinking on reference architectures is one of these best practices?

Anyway, we should start a campaign to ban the phrase best practices and smack any industry analyst or IT executive with a wet noodle everytime they use it. Instead, we should change our vocabulary to say practical considerations...

Ismael Ghalimi, CEO of Intalio makes some interesting statements in his blog regarding industry analysts...



When asked, why don't analysts cover Intalio more? He responded without hesitation and stated:Because we do not pay them anymore. I wonder if other software companies that are adopting open source approaches should also consider the same? It would be interested to figure out which other open source customers have deliberately avoided paying analyst firms? I know of several firms in the security space that felt their money was better spent elsewhere. Maybe the folks following web 2.0 could comment on the notion that if you could build a website for say $50K and generate a million dollars in ad revenue, why should one actually cut another check for say $50K to an analyst firm for a very brief mention?

The more interesting statement though is his assertion that analysts should be paid by customers, not vendors and believes this would add a lot more credibility to their work. Here is where I choose to disagree. Credibility would actually go further down the toilet but it requires some explanation. If customers were to be the exclusive payors of research, its content would surely change. It would move away from marketshare and other useless metrics that don't help us build architectures that solve business problems towards things that are meaningful to us. If you thought about it, industry analysts have it pretty easy in that you vendors have been trained to brief them on everything making their lifes relatively easy. If enterprises were to pay, do you think we would ask the same questions? Do you think they would actually get away with 1/2 hour conversations? Do you think they would know how to research problems without dependence on vendors?

In terms of BPM enabling fine-grained entitlement, I absolutely love your thinking and hope that others in the blogosphere also chime in. Would love to hear Phil Gilberts thoughts from Lombardi on this topic. Anyway, the deeper question is not necessarily whether you can support it simply via modeling but can Intalio directly consume the XACML specification so that I can centralize fine-grained entitlement? Maybe if you don't do this already, you can beat the other vendors to the jump and show them how to do it correctly.

I do have one last question that I would love your thoughts on. If you had to make Intalio integrate with an Enterprise Service Bus, which one would you choose? Would it be the one Gartner favors? the one Forrester favors? or 100% open source standards based ServiceMix?

All wise blogger Nick Malik said the following that you should pay attention to:

Business needs agility to survive in a competitive marketplace. Business is not served by cost controls that hinder creativity. In addition, IT can only be a strategic partner if it is not hamstrung by its own red tape and cost controls. If you are in the centrally controlled model, you need to lighten up, find common ground and make a new relationship between the business and IT.

For those who aren't aware, Brenda Michelson has started her own industry analyst firm. In the spirit of transparency, she has laid out how rules of engagement. Imagine what would happen if the large analyst firms did the same...



I predict that Brenda will be wildly successful because she has a real value proposition for the enterprise. She has taken the best principles of industry analysis from the folks at Redmonk but actually managed to navigate away from the vendor-oriented hey not another product we don't need mindset that is so pervasive amongst analysts. It is somewhat easy to sit back and be briefed by vendors but to figure out truly what enterprises need independent of products solving a particular problem, requires one to actually do some analysis.

There are several topics that industry analysts simply haven't covered in the past but that she will more than likely be all over. Imagine if analysts starting covering some of the below spaces:

• Enterprises not only use open source but also contribute. Imagine if the story was told about Duke Energy and their .NET framework or Merrill Lynch and their contributions to the message queuing space or even Morgan Stanley and the variety of projects they allow their employees to work on while on the clock. There are lots of contributors to open source but no one wants to tell the story of companies that are doing valuable work especially when technology isn't their primary focus.


• Todd Biske mentioned this notion of IT and Business driven SOA. The funny thing is that industry analysts and the media have keyed in on something that doesn't matter. It is never IT vs the business. They are continiums, nothing more, nothing less. I suspect that in many corporations that have had an IT practice for say 40 years that over time the knowledge of the business is more embedded within IT systems than in any particular business persons head. I defy most enterprises to gather all the business folks together to write a spec to create a new system where the results will come out exactly the same as what they currently run. IT is the business.


• Maybe Brenda will also cover innovation. Not the usual babble of consumer-driven innovation but how many EA organizations that truly have incorporated innovation into their fabric are actively pursuing patents and even giving away innovation to their competitors to help with pervasive problems in the industry in which there is no competitive advantage.


• My dream would be for her to cover the pervasive problem of lack of strong technical leadership within today's enterprises. For example, being an IT employee from an organization chart perspective is not the same as being an IT professional. When these two takes started skewing if you could chart, it would align very nicely with the rise of IT expense in the industry as a whole.

Anyway, I hope that others within the enterprise will read and more importantly support the valuable work that Brenda is attempting to pursue. I know that she has my attention...

One of the problems that many large enterprises face is in their ability to hire the right consultant. I figured I would share one tip that I started to noodle over the last couple of weeks...



Part of the problem in hiring a good consultant is that there simply isn't enough to go around. When an expert becomes available, an enterprise must respond quickly for fear that this individual will be substituted with a fresher. Sometimes are inability to respond in a timely manner has to do with our own poor time management but sometimes it is related to the process of actually interviewing.

Next week will be the start of several major projects in the security space. One of the challenges I through out to various consulting firms who are interested in placing individuals is that I told them that if they sent me the resume of an individual that blogs and contributes to open source I would make a decision within 1/2 hour and not bother with interviewing.

My thinking says that interviews in most situations are more about fit than they are about figuring out whether a person is competent. The funny thing is that the folks I respect the most tend to be the ones I absolutely can't stand working with but would hire in a heartbeat because I feel success is more important than playing nice in the sandbox.

The rationale for contributing to open source is simple. I don't have to ask trick questions related Java, XML, XACML or any other thing I am noodling but instead simply look at the quality of code they have written. This is the ultimate in transparency. Likewise, if they blog, I can also tell how they think and whether their ideas resonate with others something in which you can't really tell in an interview.

While none of the consulting firms have sent me candidates with this background, I will be making sure that this trend gets started. In the next couple of weeks, you will see me introduce several consultants to the blogosphere as they are strongly encouraged by me to blog. After all, the customer is always right...

On the chance that you haven't yet taken this survey you should do so immediately as it closes today...



For those that did take the survey, the results are available here. I suspect that most folks will throw daggers except for industry analysts who will remain notoriously quiet. In the spirit of charity, I am willing to put $100 on the table for a worthy organization: Stand to Reason if any blogger offers a 100% positive, thoughtful detailed analysis of the results.

My take on the results is that I am not alone in thinking that Ruby on Rails isn't worthy of building enterprise applications. I wonder what David would say?

In terms of the worst story on open source, Oracle seems to have the lead over Microsoft. I know that Microsoft contributes to a variety of projects. I would love to see Ellison and the expensive industry analyst firms start telling what Oracle does in the open source camp? Maybe they could hire RedMonk to help?

Likewise, many folks feel that Smalltalk is either irrelevant or don't even understand its value proposition. It would be wonderful for James Robertson to share his thinking towards why folks should still care about the language.

Good to see that folks also appreciate the importance of secure coding practices yet feel that industry analysts will only babble about products and not problem spaces. It would be good to revisit this topic six months from now and see if any of them have taken deliberate action to prove the survey participants wrong. I suspect they are too busy rationalizing their own behavior over listening to the public at large.

Likewise the one characteristic that is missing from today's IT management is the lack of strong technical leadership. In the past I have only heard one industry anayst: Brenda Michelson have enough courage to call out the root cause of most problems in corporate America. I wonder if I could persuade Alex Cullen of Forrester to do an in-depth study on this problem space?

Would love to hear the opinion of others...

I was reading a blog by Ismael Ghalimi of Intalio on the Inverted Sales Process where he states that Intalio has over 70 customers. Something must be wrong in the world of industry analysts for them to not show up in the leader's spot...



We know that industry analysts who cover given subject areas don't ever actually do real research on open source projects and instead rely on briefings. Many analysts actually never install the software they write about nor even talk one on one with enterprise customers that are using it.

Anyway, back to his posting. I have five questions that I would love to see him address in upcoming blog entries...

• In your own opinion, why isn't Intalio listed in analyst research reports? Please don't tell me it isn't because you aren't paying them enough


• There are some problem spaces in BPM that no one ever really talks about. For example, how should one integrate Intalio with Liferay Enterprise Portal such that BPM appears as a portlet?


• Marc Fluery awhile back blogged about the cost of sales which aligns nicely with your blog. The main problem though is that this is discussed somewhat under the radar. If enterprisey folk understood this, then they may be more willing to play with you. What do you think others should do in the open source community to provide amplification of the concept?


• I find the notion of fine-grained entitlement engines that allow for centralization of authorization within large enterprises compelling. How should one think about integrating the XACML specification with BPM so as to consistently secure processes?


• I would be curious to know what the average number of customers a typical BPM software provider has?

Today, a world famous industry analyst will be visiting to do a case study on us. One component of talent management is in the ability of an enterprise to motivate its employees. This has caused me to think about better ways to take care of folks in enterprise architecture organizations...



The biggest drain in terms of talent management absolutely, positively has to be the lack of strong technical leadership within most enterprises. Folks lower on the food chain should aspire not to just have the position of their bosses but to be like them in many ways. In my travels, many EAs think that their bosses are idiots (NOTE: For the record, I like mines).

The Pavlov syndrome resonates in EA more than other parts of IT. Unmotivated architects will merely push buttons and play the script required to receive stimulus. Many of them evangelize but don't believe it is their job to think and outsource all strategy to insulting firms and large industry analysts who provide four-color chock-a-block eye candy Powerpoint that lacks substance. Other EAs only exist to follow the orders given to them by their managers.

In the past folks such as James Robertson, Chris Petrilli, Robert McIllree and others refered to many of us as being too enterprisey. Many of the web 2.0 and Ruby camp see us folks in the enterprise as a bunch of incompetent morons with personality disorders. Nothing could be further from the truth. Talent is always discussed in terms of IT executives. Maybe real talent management has to do with the deliberate steps an enterprise takes with folks lower on the food chain. An enterprise with a bad culture becomes like a graveyard with only those to feeble to go elsewhere left behind.

Here are some common themes that I think should be discussed whenever talking about talent management:

• No one is motivated by 3% raises: I wonder if management has ever figured out that their job is to get as much productivity out of folks they can. This requires upfront planning, not beatings and punishment at review time for their failings to do so. What if there were a policy that stated that no manager should ever get a raise unless every single member of their team is deserving of a raise as well. This would be an interesting take on what real talent management could become.


• Make work more interesting: One of the things that amazes me is that outsourcing works only because it has a racist component to it. What if management stopped thinking that 21-year old Indians who would be happy to make more money could provide more value than just being a dumping ground. I reflect on the days that when I was 21 and if I had the choice of working for (a) A software development company (b) a global consulting firm (c) Wall Street (d) your average enterprise that has tons of legacy systems, which one would I choose? I suspect you know it wouldn't have been the last one. Do we really believe that folks in India don't think the way we do and have similar aspirations?


• Focus on the work that folks do, not how they do it: I can't say enough that we have distorted the real intent of governance. The dictionary defintion means to influence the behaviors while many enterprises who lack strong technical leadership have bastardized the word into financial control. Micromanagement, governance or whatever new word gets invented to rationalize (remember, rationalization is a trap) their behavior is the second worst thing one can do to their enterprise that give competitive advantage to competitors. Governance nowadays has the effect of causing work to move at a snails pace and guarantees that folks will put in zero personal investment in terms of making it successful. They of course will pretend to care, but we all know better...

Maybe the first thing an enterprise that wants to improve the notion of EA talent management should do is to read Frederick the Great...