Enterprise Architecture: From Incite comes Insight...

In the mail yesterday, I received two different conference brochures and was disappointed...



One of the brochures I received was for Enterprise Architecture Summit". The conference is all about enterprise architecture yet they don't really have even a single enterprise architecture practitioner presenting. In fact, if you look at the speakers list, all but one person (Gunther of Siemens) either works for a consulting firm or a software vendor pitching thinly veiled sales presentations. It seems as if they have the same faces every single year. I wonder if attendees wouldn't appreciate a little more variety?

Maybe the problem with conferences is that the economic model behind them is fundamentally busted. They choose posh facilities where rates charged by the venues are obscene which results in the only way to cover costs is to bring in lots of software vendors who of course pay a fee for a booth. Likewise, if vendors pay money they demand a speaking slot and it goes downhill from there.

I guess my recommendation to my peers in large enterprises is to avoid this type of insanity. One conference host that doesn't allow vendors to speak yet provides high quality topics and speakers is Marcus Evans. They also have a unique value proposition for vendors as well.



I also received the brochure for the Java One Conference which has hundreds of different sessions but yet I couldn't identify not a single speaker from a Fortune enterprise whose primary business wasn't technology? I wonder if attendees of conferences are no longer interested in case studies?

The one thing though is that should receive a lot of attention is the support in Mustang for a scripting engine of which several sessions will focus on. The specification will describe mechanisms allowing scripting language programs to access information developed in the Java Platform and allowing scripting language pages to be used in Java Server-side Applications.

One perspective says that languages such as Ruby will now be able to participate in enterprise application development while others may be of the belief that Ruby will no longer be relevant if you can do scripting within the Java platform using languages already familar to the enterprise. Only time will tell which direction the enterprise goes. Of course it is my prediction that large enterprises will take a different path than what is currently being hyped in the blogosphere.



With scripting support, Java will continue to grow by leaps and bounds and may even be the death of other languages delegating them to second-class citizenship. Other features that many of the conference attendees will be talking about that matter include discussions around clustering support, native platform GSS/Kerberos integration, Support for the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) and the ability to integrate enterprise applications into management consoles via the JMX protocol. I wonder if I can find the equivalent discussions happening at Rubycon...

At work, several of my peers have expressed an interest to share even more information about our IT practices with industry analyst firms who are willing to do five page case studies on us where we are the exclusive focus (not comingled with other enterprises). We have pinged lots of analyst firms and for the most part all have been receptive. I have noticed a pattern here though, that I find intriguing...



We have decided to share our thoughts with analyst firms on the following topics:

• SOA Governance


• The Human (vs process) aspects of enterprise architecture


• How innovation occurs in corporate environments


• Metrics around enterprise architecture and the value it brings

We contacted analyst firms of which we subscribe and don't and both types were receptive. Part of our constraint in this undertaking is that we offered up an opportunity to come onsite and interact with lots of people instead of just doing briefings over the phone (face-to-face conversations are always better). It seems as if the larger analyst firms tend to either have analysts already on our side of town negating any travel costs for them and/or had plans to meet with other companies in our area and was game to schedule around it.

Enterprises are wonderful places to practice one's profession. The opportunities abound to have meaningful dialog with others is immense. There are many folks in the blogosphere who have the outsider looking in perspective and miss the point for a game changing conversation. One of the things in arranging these case studies is that I felt it was important that I only be a coordinator and not a participant so as to not establish a perception that its all about me. I wanted to make it all about others. To a certain extent, the notion of declarative living should demand this behavior of others.

In previous blog entries, I have always encouraged industry analysts to explore the ecosystems of other enterprises. I am a big fan of Duke Energy who not only uses open source but made a conscious effort to give back to the community. There are lots of other enterprises whose primary business model isn't about technology yet they have a strong sense of community. Stories on these companies need to be told and amplified for others to hear. Enterprises aren't evil but the folks that refuse to tell their story may be...



The funny thing is that I am passionate about not telling the story of my employer. It is not that we don't do wonderful things, reality states that we have the premier set of architects in the universe and it is futile to think that any company could assemble an architecture team that is better than ours. Most folks assume that because I talk about enterprise topics that I must somehow be talking about what goes on at work. They would be guilty of reading "into" too much of what I say. If I happen to be employed by or the folks whom I have open conversations with work for such Cigna, Aetna, Travelers, Prudential or Lincoln, their names doesn't really matter as folks would get caught up in focusing more on name-dropping than the actual intent of communicating in the first place.

Are the demographics of who are paying clients to industry analyst firms look different if you are small vs large? I could only find information that Forrester attempts to make sure that us "enterprise" folks make up 1/3 of their paying client base. Would love to know general industry statistics in this regard.



Anyway, I would love for others to provide me with their own thoughts on what other topics would you like to see large enterprises sharing with others? The story of vendors, new software development languages such as Ruby are uninteresting when juxtaposed against what occurs in large enterprises. Of course, I will be fighting an uphill battle to get others who are otherwise outsiders looking in to see what I see and therefore will be perceived in many unpleasant ways but I am savage in my beleif that if real perspectives on enterprises are allowed to emerge, the outsiders may come to appreciate alternative thinking. The journey is long and I hope they have the stamina to keep up...

I am a big fan of open source especially within the enterprise. The problem remains that certain aspects of innovation would never occur in an open source way. For example, if you look into the security space for ways to encrypt hard drives, you will find a wonderful product named truecrypt. The problem is that the open source community will view any form of "backdoor" as evil yet many laws that corporations adhere to require them...



Pretty much every single corporation requires the ability to have key escrow functionality in encryption products so that whenever they receive subpeonas from their favorite attorney generals for information they can comply. They also have to adhere to a variety of laws so as to keep the workplace safe from those who have pictures of kids on their computer. All of these require backdoors into the protection mechanisms. Projects such as truecrypt have taken the perspective that backdoors are evil and therefore they will never gain the support of corporate America and its ability to throw large pockets of cash at the problem space.

Many enterprise architects are big into the notion of IT governance (I am one that is but of course use a different definition). Since the open source community by its very nature wouldn't ever have the personal need for governance frameworks, it would be challenging to see any useful solution emerge in this space.

Other areas which are also rarely explored are software projects targeted at the mainframe which is partially due to the fact that much of open source is written on commodity Intel platforms and therefore most people don't have access to a mainframe to do such development. There are many wonderful opportunities that could be explored here. Imagine if Ruby on Rails ran on Z/OS? What if the Mono Project were also ported to Z/OS? What would happen if someone wanted to write an open source equivalent to RACF and/or Top Secret that plugged into the SAF interfaces? The community of course could extend this code to make it directly support SPML, Infocard and SXIP.



If anyone has thoughts on how to change the perspective of the open source community so that it becomes even more open, then please do not hesitate to trackback to this post. Let's continue the dialog...

Several individuals provided private feedback on a previous blog entry where I suggested the agile community needs to grow beyond its founding members and reminded me of the fact that if this doesn't occur in a controlled fashion that words will be hijacked by larger consulting firms in order to sell things that the enterprise may not truly need. All of them agreed that the word agile has been distorted, overused and abused in corporate settings and therefore championing it nowadays may result in better buy-in at the expense of worse execution. They also asked me to think about the topic of enterprise architecture and soon how it to may follow the same path as the word agile...



I have always believed that Government enterprise architecture is a big fat joke! They literally got an act of congress (e.g. The Clinger Cohen Act) mandating enterprise architecture practices for all departments. If only in corporate America we were so lucky. Having to "sell" the value of enterprise architecture takes away from time to actually "practice" enterprise architecture. Folks in the Federal Government were blessed to have one pain point removed from their "process" yet missed the opportunity by turning it into big ceremony around the creation of bureaucracy and lots of comprehensive documentation that few people have actually read.

For the most part, government IT is outsourced to a variety of consulting firms who have a vested interest in extending their contracts indefinetely, not cooperating with other consulting firms in which they compete and otherwise making something take a lot longer than it really should. Of course, there are lots of folks that can find positive in a pile of negatively and spin it to make it look like a success, but we all know that reality states otherwise. It does beg the question of whether any form of enterprise architecture should be handled by consultants and what can corporate America see and learn from our government as to how not to do enterprise architecture.



I have spent more of my life as a consultant (distinct from contractor) than as a full-time employee of a large Fortune enterprise. I remember one project when I was a consultant where I worked on a trading system application and its strategic direction and it was supposed to take ninth months. We actually prototyped the system and got the traders to like it and agree to put it into production in four months and it was wildly successful. The client of course, felt that he paid for ninth months of time and made a stink, so the team sat around taking turns sitting in front of Microsoft Word cutting and pasting from a variety of third-party documents to create a set just for this client. Over time I have learned that lots of folks were later forced to read something that provided no value but did so simply because this was the process.

In other consulting gigs, I remember doing what I will refer to as "architecture by Powerpoint" which essentially was the savage practice of drawing "cartoons" type presentations that provided such a high-level view that it could not only describe the future state of your organization, but anyone else's as well without requiring changes. IT executives loved this practice. To me, this was a necessary evil in order to get to the next step. I remember on multiple occasions finding better ways that could help the client save money and to help them increase the producitivty of their staff but was met with resistance because they didn't really care. They already developed their own "pitch" to their bosses and changing things even for the better would result in confusion.



Fast forwarding to today, having seen both sides I have come to the conclusion that non-employees of large enterprises should only provide guidance in certain aspects of enterprise architecture but otherwise shouldn't be practicing it. If I had to recommend a few things to others considering hiring consultants to provide guidance, I would suggest that their backgrounds be probed for the following elements which are predictors of success:

• Understands that IT/Business alignment is a rallying cry and not an indicator of change in skillsets. The business community needs great IT people. We can't all be spending time aligning with the business and someone needs to pay attention to strictly IT issues. Its all about balance.


• Some hands-on experience with Agile Software Development so as they can guide you into lighterweight ways of accomplishing the same goals.


• They should be speakers at conferences. The industry itself will tell you who is worthy of your time. It will also tell you if they have been successful in the past of truly articulating the value proposition of EA


• Is more aligned with Enterprise Architecture 2.0. The enterprise doesn't need enterprise architecture historians


• Has worked not only in a variety of industry verticals so as to provide cross-polinization but has worked for a wide-variety of size firms ranging from Internet startups to Corporate environments. The ability to understand the "business" and the stages it goes through is crucial as everything evolves.


• Has a strong sense of community and not only analyzes them but actively participates. The future state of the enterprise architecture is community driven and there should be a preference for those who have had an early lead.

Danny a dutch blogger said something intriguing regarding software development in Ruby that should be considered...



I encourage folks to not only read his post but to provide some amplification to it. I figured that there was one aspect that I wanted to provide my own perspective into which of course I will be setting myself up to get attacked again. The notion of prototyping in front of a customer using either Ruby or Java for that matter by a slick developer should be discouraged for a variety of reasons, including but not limited to:

• In many shops, business customers will be esctatic to have IT folks show them there work in a rapid manner, but IT folks have somewhat of a fidicuary duty to maximize the time not spent by the business community on IT related issues and let them focus on their core competency. No, this doesn't justify current approaches in this regard, but it doesn't also mean that we should be making them watch us code.


• There are simply better ways to prototype nowadays. Minimally, the business person is interested in seeing that IT understands the business process. This can be captured using any of the BPM modeling tools. Likewise, there is a new breed of emerging software category known as simulation software. Maybe the community should check out offerings such as iRise and its competitors?


• A coded prototype is more functionally rich than the static prototype. The coded prototype, however, makes a long development cycle even longer, because instead of reducing the amount of coding overall, it adds to it. Furthermore, coded prototypes are difficult to change, remain in the domain of the IT specialists and cannot be managed by the business user.

A couple of weeks ago, I learned that Pratt & Whitney, a manufacturer of aircraft engines started to source most of its work from other countries at the expense of local machine shops who were savage in not only increasing quality over time but also in increasing productivity of its workers. The executives at Pratt & Whitney figured out that it was cheaper to have the same part made by several different manufacturers at the same time, choosing the one that was best produced out of the bunch and throwing out the rest. Will IT also follow this same path?

Agile software development has the power to change how software is developed within corporate America, yet it hasn't been embraced in any big way. Figured I would throw out some thoughts to the agile community on how to increase its uptake and do so in a rapid manner...



1. The community has been well-served by the founding members but it is now time to find others to be the keeper of the flame. Communities grow and thrive when constraints to their growth are acknowledged and addressed. Imagine what would happen if the agile community got several folks who work for Fortune enterprises to not only passionately blog on agile (Scott Mark comes to mind) but invited these same folks to be keynote speakers at industry conferences.

2. Awhile back, I mentioned that I may consider no longer championing agile approaches which in hindsight, my perspective was more about the banner vs the practice. Reality dictates that the open source movement is also an agile method. I have always asked myself about the corporate partyline that states "we have a communications problem" whenever there are massive failures. The open source community has developed operating systems such as GNU Linux with thousands of developers who have never been in the same room, never participated in listening to the guidance of the all-wise potentate leader nor have even heard each others voice yet they continuingly deliver valuable working software. Is "communication" or lack of really a crutch for the lack of conceptual integrity? If so, emphasize better architecture over better communication.



3. Extreme Programming feels right in a coprorate setting but is it too a crutch for corporate dysfunctionalness? The notion of pair programming and encouraging developers to get feedback from another individual at one level is an incremental improvement within most environments while in another sense, wouldn't it be better for them to get feedback from the world? I think that one of the things that helped me improve as an architect is not the sterile feedback I tend to get in a corporate environment where everyone due to HR practice tends to be tempered and cordial but in the feedback by folks in the blogosphere who have taken my own thoughts and improved on them and likewise have given me brutally honest feedback whenever I slip. Isn't the real problem not about feedback from a single individual but the lack of open communication?

4. Doesn't extreme programming actually encourage tight coupling. Tight coupling of developers works at some level, but wouldn't a switch to looser coupling over email and common web sites increase productivity and increase the amount of folks who can participate resulting in better scale? I have yet to find a corporate environment at any large scale that has work environments truly suitable for pair programming. The cubicle mindset can't be easily fixed because this is not controlled by IT. Wouldn't it be better to change to approaches that IT does control?



5. The agile community at some level avoids talking about other efficiency gains that could be realized in corporate environments. For example, if I bring in my favorite consulting firm in to help with development of a new enterprise application, they may bring in new languages that help deliver it faster but what about reducing the total cost of ownership over its lifetime? What if multiple potential customers could combine forces and allow a product to be developed across corporate boundaries spreading the cost of development? The cost of lost productivity would be more than made up by the spread.

6. The agile community is savage in supporting the building of test cases first yet this seems disconnected from the contracts they sign with their customers. Would you convince more customers if payment wasn't based on either hourly constructs or fixed bid but instead payment for test success?

7. Would the agile community support the notion of developer ratings as a way to mitigate perceived risks of agile? Many enterprises are worried about working software that is unmaintainable just to get the next paycheck. What if there was a Slashdot-like moderation system where developers could be rated. If an agile developer writes unmaintainable code, their rating goes down and customers would get to see it in a more transparent manner.

Was searching the Internet for upcoming conferences when I came across one topic from a past session that caught my attention...



Justin Gehtland describes in a session what it means to build an ESB, and how to do it with open source technologies: Spring, Mule (from Codehaus) and Rails. We'll see the messaging layers, the integration of Spring and Mule, and a little cross-platform goodness just for good measure. He shows how to build an actual Enterprise Service Bus from the ground up using Spring, Mule and just a touch of Ruby.

In reading his blog, I found that he is very knowledgable and thoughtful. I am curious though as to what other definitions are out there for enterprise service bus and showing someone how to build one during a conference session is a good idea? I have found that in my own travels, I couldn't get a definition for what an ESB as it would consume hours. I would love to hear a podcast of this presentation.

Curious though, why anyone would want to know how to build and ESB when you can simply download one that is of higher quality that one that throwns in a touch of Ruby. I wonder why others aren't blogging on ServiceMix. It is the only ESB, open source or otherwise that runs on 384 CPUs.

Lot of folks have chimed in on a previous posting on Ruby and responded with passion and supplied their own perspectives but zero facts. One of the reasons I blog is that in my travels, I tend to talk to lots of folks and hear interesting perspectives in which I share here. My blog clearly mentions that I talk about the human aspects of technology. Some folks will get it twisted and think just because I wrote it, means that I must believe in them...



I am probably guilty of assuming that folks would come to understand alternative perspectives over time and not simply react without understanding a larger context. One person assumed that because I mentioned Duke Energy that I must somehow work for them. Wrong! My mention of Duke Energy was do to the fact that they are a large enterprise that not only uses open source but has taken direct action in order to give back. I simply want others to understand their perspective and desire that folks who work for magazines start telling this story. I wonder if Chad Dickerson could provide insight into how to make this happen.

Another incorrect perspective is that I somehow believe in analyst conferences are the holy grail. Not! For the record, I have never in my entire lifetime ever attended a single industry analyst conference nor have any current plans to do so. Folks who threw out this assertion also suggested that I didn't know how to use google when I could say the same thing of them as they would see no less than ten posts on my thoughts on industry analysis.

Some folks have assumed that since a large percentage of my photos show republicans in amusing ways that I must somehow be a democrat. Not!

Still others responded based on my comments on books within the marketplace and assumed that my comments were because I wanted to somehow promote my own books. Not! Bet you didn't know that all those books that won the Jolt awards had to pay a fee of several hundred dollars and that they weren't selected from the entire universe of books on the subject? If you have a contest where everyone is welcome to pay a fee, yet only one book within a category does and then is declared a winner, shouldn't that bother the community especially if the author hides this fact?



Still another perspective is that I am a thought follower and defer my entire thought process to the wisdom provided by large consulting firms. Wrong! I simply acknowledged that this is a behavior whether right or wrong hapens in corporate America.

I find it somewhat amusing that others still believe that I am a big believer in only acquiring technology through large software vendors. Reality dictates otherwise. One may have noticed that I have several venture capital bloggers on my blogroll who fund startups that may have at best ten employees. If you look historically at my blog, I have encouraged others to look at a variety of small companies.

I still cannot stop laughing about the postings regarding me being too enterprise. These are from folks who have obviously never met me or even engaged in an open conversation. I suspect their perspectives would change if they did so...



One of the things that I did learn in this undertaking is that the blogosphere works pretty much like corporate America and that many of the folks that went on a rant are more corporate than they think. In many of the environments that I have worked in, whenever someone makes a slip there are folks who will capitalize on it for their own benefit. It is rare in corporate America to find folks who have a genuine interest in helping each other and do so without attacking in some form or fashion.

The dialog (for lack of a better word) with the Ruby community generated more traffic that I had expected. I promised within my blog entry to respond to each and every person's question as I hoped to bring about alternative perspectives which was a fatal mistake. In responding to over 100 different folks, I started to journal the response across multiple posts promising to address each language within a separate entry. A couple of folks responded with comments in the dialog with statements about Rexx, PHP and Smalltalk in which I inserted in my thought process and responded to as if it was about Ruby. I later went back and edited this particular aspect as I thought it was important for the posting to reflect what I was thinking at the time in the most accurate way possible (NOTE: The changes were contained in all of two sentences. 95% of the posting did not change). I guess some folks felt that I was attempting to hide something which as a thought didn't even enter my mind. I guess I somehow violated some rule of the blogosphere that I wasn't aware of. Maybe, I too didn't get the memo.

Anyway, I hope that the Ruby community can at least respond going forward with facts instead of merely their perspective on the enterprise and provide an answer to the below questions. I am willing to put my money where my mouth is and make a donation of $500 to any of the charities listed within my blog or any other mutually agreed upon charity for anyone that can provide fact on any of the below questions within the next thirty days:

1. Please provide the URL to any publicly available case study on Ruby where it is being used by a Fortune 200 enterprise where it is the primary development language for an enterprise application (using any definition I have mentioned in the past within my blog, sorry you can't make up your own) that is currently in production.

2. Please provide the name of any full-time employee (not consultant) of any Fortune 100 enterprise that will be speaking at any conference (or user groups where attendance is over 500) that will focus on their usage of Ruby. Also include the URL to the conference brochure.

3. A copy of any major IT publication (e.g. Infoworld, eWeek, etc) that has circulation over 50,000 copies where a single IT executive of a Fortune 200 enterprise will be on the front cover and within the article, they mention they are displacing other languages in favor of Ruby.

One rule is that Fortune enterprises mentioned must not have their primary business in technology. Another rule I ask is that any responses to this posting stay exclusively focused on Ruby and not any of the other dynamic languages so that I don't repeat the same mistake in future responses.

I am asking the Ruby community to please prove me wrong with facts as I really want to give monies to charity and need your help. While I value any additional perspectives that may emerge from this type of questioning, I do ask that you not "read into" my motivation for asking them...



NOTE: I will be deleting all responses that are not fact-based...

I think I have discovered a predictor of enterprise adoption and its
correlation to the maturity of a community that I wanted to share...

There are several communities that have had rapid uptake within the enterprise. Many of these communities were successful in that they had several factors working in their favor. A quick analysis of communities whose uptake is a lot slower reveals common behavior patterns that are important for enterprises to consider before going down the path.

For example, The Agile Software Development community has a great value proposition that many enterprises should seriously consider. The simple fact though, is that uptake within enterprises whose primary business model isn't in technology have not really adopted it in meaningful way. While there are success stories out there, many of them are based on pockets of activity within the enterprise while other successes go unpublished. Wildly successful communities have removed many of the constraints that hinder uptake by letting the community grow above and beyond its original founding memberswhich will attract more media attention which results in more awareness.

Another characteristic of successful communities are their support for thosewho prefer to take an easier route to learning than to geek out and do deep research. It is well-known that the characteristics of being a successfuldeveloper within a large enterprise is vastly different than being a successful developer that works for a consulting firm or software house. Communities thatsupport those characteristics tend to have better uptake at the enterprise level. Communities that never really cross the chasm, fill their egos by attacking others and take pride in pointing out to folks that they should RTFM.

Below are several communities that have been successful and have a high level
of maturity...

I suspect that no one in the past has attempted to compare the dynamics of distinct communities. Of course, each has its own strengths and weaknesses. Whatis important though is that strong communities are savage in increasing their maturity...

Figured I would take the opportunity to post a wonderful job opportunity for a savvy software developer that is interested in working for a large enterprise writing security-oriented code. The right candidate will have the following background:

- Ideally has developed enterprise software in several languages
- Has been an IT professional for at least ten years
- Absolutely loves to code and doesn't have an interest in moving into management (at least in the short-term)
- May want to develop open source software as part of their day job (not guaranteed but good probability)
- Wants the safety of a large enterprise while not being caught up in corporate bureaucracy
- Degrees don't matter, but strong work ethic does
- Not only any form of VISA since we do not sponsor
- Can pass a reasonable background check
- May travel a total of ten miles one every other month to visit a satellite location

If you are interested in this position, please leave a comment...

Yesterday at work, I visited our media relations department pitching an idea on how I wanted to externalize a strategy I have been working on in the security space. Awhile back, I blogged on Sharing IT Security Innovations but it was my original thought that I would share it with industry analysts and many of the key software and consulting vendors we worked with. My contact suggested that I change my presentation slightly and figure out how to share it with a few other large enterprises (no NDA required).

If you are an Enterprise Architect, Chief Security Officer or CIO/CTO and currently employed in a full-time capacity (not a consultant) to a Fortune 500 enterprise in any of the below listed industry verticals, I would like the opportunity to share it with you. Please leave a comment along with your work email address (I will not consider responses from non-work addresses).

• Retail Banking


• Capital Markets


• Healthcare


• Investment Banking


• Defense and Space


• Telecommunications


• Pharmaceuticals

In the future, I will expand out my sharing to folks outside of these verticals...

Figured I would share all of my upcoming speaking engagements. Hopefully, if you will be in attendance at any of these events, please leave a comment...



April 2006

• InformationWeek Spring Conference: Will be on a panel discussing service-oriented architectures. Would love for audience members to ask questions around open source how it can help create them faster and cheaper.


• Long Island Java Users Group: Doing a presentation on extreme scalability. Will dive deep into what it takes to design an application to run on 384 CPUs

May 2006

• Infoworld SOA: Will be on a panel discussing service-oriented architectures. Would love for audience members to ask questions about security and management aspects to developing enterprise-class services

June 2006

• Enterprise Open Source Conference: Will be presenting on how enterprise architecture practices can embrace all aspects of open source and not just focus in on getting software for free but to make the enterprise and the planet better at the same time

2007

• RubyCon: Will be presenting on how the Ruby Community has embraced enterprise thinking and provide a status on the port of Ruby to Z/OS. Will also present a case study on the first enterprise application in production within a Fortune 100 enterprise written entirely in Ruby


• Agile Software Development: Will be talking about the growth of the agile software development community and how they have crossed the chasm. Will provide several case studies using analogies of how Six Sigma and CMM grew beyond the original creators enabling its success


• Agile Software Development: Will be talking about the growth of the agile software development community and how they have crossed the chasm. Will provide several case studies using analogies of how Six Sigma and CMM grew beyond the original creators enabling its success and increased the velocity of uptake.


• Enterprise Architecture Summit: Will present several case studies on how enterprises have finally gained control of their own destiny, have standardized on a set of tools, enabling consistency and interchangability amongst its development staff reducing the overhead of having disparate skillsets. One of the case studies will feature a large enterprise who no longer lets every new product claiming productivity gains sneak into the backdoor but forces those who bring them to walk through the front door with facts on adoption rates amongst peer groups, depth of integrators supporting it and quantification of marketshare


• OOPSLA: A deep dive into how the agile community has realized that Individuals and Interactions are more important than processes and tools and why they should continue to put more value on interactions with those who share different perspectives so that all communities benefit...

While other enterprise architects are running down the corridors talking about IT/Business alignment, I am busy figuring out how to become a better steward of what they truly desire of IT; valuable working software. I was thinking about past blog entry from Lombardi's CTO Phil Gilbert and realized that most folks in large enterprises have never even looked at BPM from a software engineering point of view...



I am patiently waiting for the time when a traditional BPM vendor may show how their product offering should integrate with an enterprise service bus such as ServiceMix in the form of a reference architecture. Maybe, it is too much for us enterprise customers to ask of BPM vendors. After all, we really shouldn't attempt to understand how your product may work with others...

The funny thing that is happening is that many folks who have aligned themselves to BPEL and/or BPM seem to be developing service-oriented architectures with the notion of orchestration being pervasive. I am of the belief that they are being led into a rathole. Over time the notion of choreography will supersede service orchestration. When it does, what then becomes the value proposition for BPM?



Phil's comments feel a lot like choreography as he understands how human-oriented architectures and the processes that surround them really work. What would happen if we all started to think about choreography-oriented architectures and figured out a way to describe activities in this way? I suspect it may fall apart in the short-term since BPMN in my reading of the specification doesn't allow one to depict the process of establishing an agreement in a multiple party scenario. Likewise, BPMN has no ability to even model what the decision (aka contract) that came about from this form of interaction.

I wonder if we could convince Phil to show leadership to the rest of corporate America by taking these issues head-on in his blog. I would love for him to hook up with David Lithicum and James Taylor to figure out better ways of developing valuable working software for the enterprise. Maybe the first question these folks could collectively blog about is when/how should business rules engines should be incorporated into a BPM architecture...

Continuing the thought on Why Ruby it isn't enterprise ready. Of course, many folks in the blogosphere will pick out a sentence or two and quote it out of context. Don't get it twisted, consider all points, don't pick and choose. Although, some bloggers can do so in a humorous way:

So leadership consists of knowing of whose lead to follow? I guess we can just wait for Gartner or Forrester to establish a conference on jumping off of bridges and McGovern's leadership will take care of itself.

I guess I should cut this person a break in that they haven't read prior blog entries to know my position on following analysts. After all, that little search button on my blog if filled with the words industry analyst might not provide a different perspective...



Another bonehead decided to key in on one phrase stating the obvious that no one negotiates a contract with a vendor named Ruby which of course missed the entire point. If other architects are not currently championing Ruby and the large vendors such as Sun, BEA, Oracle, IBM, etc are not currently Ruby and even large integrators aren't. then the only ones that may champion Ruby are vendors that enterprises may not be using to develop enterprise applications hence the contract notion. You can get it twisted by focusing on contract negotiation as an agilist or you could attempt to figure out how the large vendors and integrators can increase their margin by adopting it.

The problem I think the community has is when folks separate what they like from what they will "recommend" and push for the enterprise. In talking with other architects in corporate America, they too have came to the same conclusion. It doesn't matter if you feel any perspective I state is valid or not, what matters is that others may be thinking the same thing and it is in the best interest of the community to have canned answers to them. Oh by the way, don't get it twisted and think that every single opinion is my own because that would be highly inaccurate...



Here are some additional thoughts / points in no particular order that folks should seriously consider:

1. Productivity is elusive. For example, if I hire two different insulting firms whom both practice agile methods where one uses Ruby and the other uses Java, I can predict which one may deliver an application quicker to me, but I can't predict which one will cost less. Let's say I decide to hire folks from one of the more prominent agile consulting firms who will charge me a higher hourly rate and uses Ruby whereas the other insulting firm who practices Java and Agile Methods but is from India takes a lot longer but has cheaper hourly rates, which one will be cheaper? The real answer is when I receive the "bids" from both parties, they will be competitive. Don't get it twisted in thinking about my example using folks from India as this would miss the point. The real point is that folks in the agile community cost a lot more than folks not in the agile community even when both are from the same country and have the same types of experience. I may not even have visibility into the productivity games and the insulting firms will want to keep it as margin.

2. Costs within the enterprise are not in software development anymore. Have you seen the electrical costs within most data centers do to all those inefficient but rapidly coded applications? Maybe you have figured out that within most large IT shops that if only 25% of the folks there know how to code then productivity gains here aren't as significant as say realizing savings from say operations where more folks reside. How does one save on operations costs? The answer is easy, one may choose languages that exhibit better performance and scalability characteristics than one that doesn't.

3. Continuing the thought, Ruby currently doesn't realize the above characteristics. Maybe if it added native thread support, this aspect may go away.

4. Another deficiency that Ruby needs to consider is that not everyone on the planet speaks the same language. Enterprise applications (I really should post a definition for this but will save for another blog entry) in many shops and as written by many large software vendors need to support multiple languages simultaneously. Ruby needs to address multilingualization quickly.

5. In my career, I have noticed that folks who know Visual Basic tend to not get multiple threading architectures and will make design level mistakes. Ruby folks as another predictor (different from guarantee) tend to not design (Yes, I know the agile party line here) and are successful in getting applications to work quickly but tend to skip out on long term maintainability. Maybe the best thing that Java folks can do for the Ruby community is to bring more of a software engineering mindset to development.

6. Ruby is going down a path of creating their own Virtual Machine. It seems to me, that they should simply put Ruby on the Java VM and not waste efforts in reinventing the wheel.

7. Ruby should support the notion of being about to be embedded into other platforms vs. simply being standalone.

8. Ruby needs to be supported on more platforms? The attention seems to be only on Windows / Unix / Solaris and easier to reach? What about the other platforms used within the enterprise?

9. Does anyone agree that the notion of packages / namespaces should be a part of every modern language?

10. While everyone has their own definition of the word enterprise and therefore it is somewhat overloaded, I have in the past used it to represent a sales model and how software is sold. Some folks would argue that product X is not enterprise ready when they are merely indicating that there is no one available that can do powerpoint to my audience. What could the community do to address this in order to increase adoption?

11. Shouldn't the notion of methods being public, private and protected also be a part of every modern language?

12. Let's say that Ruby steps up to all of the things I listed above and does so in a rapid manner, wouldn't that break all applications that used Rails? I believe the answer is that it would cause a trainwreck for any enterprise application that was built on top of it?

13. Does anyone in the community acknowledge that software vendors and even many large enterprises don't build on top of scripting languages because they don't want their intellectual property so discoverable?



I suspect there will be lots of folks spending time countering all of the above thoughts and of course will not even pay attention or even from an open minded perspective consider what I am about to say. Anyway, I figured instead of going on a rant, I would volunteer to help the Ruby community step up so that enterprises wanted to use it and offer my guidance if you are willing to consider it from an open mind. The following things need to happen though:

1. We need to get a port of Ruby running on Z/OS so as to offer competition to Rexx.

2. I figured it is important in the name of transparency for me to declare exactly what I will get out of this effort after all nothing in life is for free. One perspective that I have been working hard on changing is that the open source community is all about software vendors. The magazines never seem to want to cover stories of large enterprises and their contributions to the open source community. If you could get Jon Udell from Infoworld to do a story on Duke Energy and their contribution to the community of a wonderful .NET framework and they would be willing to put a mugshot of a Duke employee on the front cover, I will no less than 48 hours expose a mainframe to the Internet that will allow for the first bullet to begin.

3. I support the agile community in some aspects but not in others. Over time I have come to realize that the principles are sound, I just sometimes question the motives of their founding members. The Six Sigma and CMM community for example, are huge nowadays because their founding members allowed it to grow beyond them and didn't put any artificial constraints on it. The agile community has reached its crest and cannot grow any larger because it would require its founding members to let it grow beyond them. As a test, ask a Six Sigma and CMM practitioner for the founding members names and I suspect they couldn't tell you without researching it first. Not knowing the founders is a good thing as it is a testament to one's ability to grow. I ask that the Ruby community not make the same mistakes as the agile community in this regard...

Ran across a wonderful article by Mike Edwards who is an Enterprise Architect consultant in the UK. Figured I would share portions of it that aligned with Enterprise Architecture 2.0...




At every step we must leap, run and change direction, all while communicating EA-centered values


Each incoming executive needs to make his or her career-enhancing mark, and will do so by way of innovation and change. Micro-visions and empires flourish but die over a short time space, whilst technologies change and enable new value and new capabilities that were un-thought-of 12 months previously


We should begin to think of EA as a State of Mind - a cultural awareness, spirituality if you will, that does not have to even be known as Enterprise Architecture


The answer lies with the strategic thinkers in an organization. Savvy strategist realize that their view of the world is not fully appreciated by all. They know that it is not necessary to make everyone fully understand EA in order for EA to succeed. However, it is necessary to find the motivators that each stakeholder needs to succeed in their own area and to marry these motivators together.

To summarize, the key principles of value within Enterprise Architecture 2.0...

1. Always know your architecture's purpose at any point in time.

2. Always know how the architecture's stakeholder users are and what they want from it.

3. Have the ability to measure architecture in order to derive its value - whether that is in terms of cost, time, risk-scoring, resource needs or other metrics.

4. Promote the value of architecture rather than the vision of EA. Promote it by way of motivating stakeholders to participate.

5. Let the Nirvana of an EA culture by way of the success of value-oriented architectures. Actions speak louder than words.

Have you ever noticed that the only folks blogging on the merits of the Liberty Alliance happens to be software vendors? My hypothesis is that the Liberty Alliance simply isn't addressing problems that matter and/or are of lower importance to large enterprises than what the XACML specification and implementations based on it can offer as a potential...



For a good overview on XACML, please click here. Of course, I have my own questions on XACML that are outstanding. Hopefully vendors who offer solutions in the XACML space and the analysts that cover them will trackback this blog entry and start meaningful discussions to provide answers to some of them below:

• How should one store XACML based policies in LDAP?


• How come no book publisher has considered a book on XACML? (Tim Oreilly, please step up)


• For the folks that created JSR-168, shouldn't they be thinking about accepting XACML via a standard portal API? (Liferay Enterprise Portal will be the first Enterprise Portal that supports XACML


• How should XACML interact with WSRP?


• I really would love for Gartner to create a quadrant and Forrester a Wave on XACML compliant products. What would it take for them to get one out the door, say by the end of April?


• It seems as if only the folks at Burton Group are talking about XACML publicly. How come they are the only industry analysts that realize its potential?


• Jericho Systems and Securent seem to be the early leaders. Who are their emerging competitors?


• Identity Engines seems to be talking about another important space not well discussed: enterprise guest management. Could this become a part of Compliance Oriented Architectures 2.0?


• Other vendors that compete with Identity Engines such as Nomadix, ValuePoint Networks, Pronto Networks, Roving Planet, Device Escape, Enterasys and Trapeze Networks all seem to be thinking about the same space but can't tell why they aren't also embracing XACML.


• Kim Cameron talks periodically about spam and identity. I wonder if he would start talking about XACML in context of whether a user can send emails, etc.


• The notion of fine-grained entitlements actually seems more important to an enterprise than the focusing on provisioning which many analysts are currently focused on. Likewise, many of them are covering auditing-oriented products such as IPLocks and Lumigent. Should they really be separate products or should they be a component of a larger entitlements strategy based on XACML?

The word free in our society can have multiple meanings. As an agilist, one freedom rarely discussed is the freedom for collaborative, self-organizing teams in large enterprises...



Would enterprise architecture improve in corporate America if it wasn't so focused on process and frameworks but on the human aspects? If the focus changed to allowing folks to be human instead of pontificating the latest buzzword, would we truly start to understand the problem and be able to propose cost-effective sound solutions?

Virginia Satir and Norm Kerth have defined a list of freedoms in which I have modified for enterprise architecture practitioners...


1. The freedom to perceive things as they really are.

2. The freedom to say what you think and share your feelings without fear of discrimination or retribution.

3. The freedom to ask questions, to ask for information, to ask for what you want.

4. The freedom to make decisions to do the right thing.

5. The freedom to be creative, to take risks and make mistakes.

6. The freedom to learn, to change, and to seek improvement.

If small is the new big and open is the new agile then why can't freedom be the new enterprise architecture...

I previously blogged on Large Enterprises and why they don't care about Ruby and was rightfully accused of bashing folks in the Ruby community but not providing the answer to my original statement. Figured I would set things right...



The focus of this blog is on Ruby and not on other dynamic languages. For those, they will get their own blog entries. Ruby, to me feels like a trainwreck waiting to happen. So lets list out reasons why Ruby currently makes zero sense for developing enterprise applications...

1. While there are lots of books on Ruby, none of them are good. Most are mediocre and deal with the simplistic aspects of writing software. The publishing community tends to focus on introductory titles and eschew books that are for folks who already know how to program, which constrains one's ability to do anything complex. Of course the agile community, doesn't count learning on the job as part of the cost of a project...

2. For shops that have mature enterprise architecture practices, they simply don't allow insulting firms to propose architectures for them. Of course, the Federal Government does this fatal mistake all the time, so it doesn't surprise me about DARPA. Good EA practices start with not only acheiving cost-savings, enabling the strategic intent but also add consistency. We all know that Government Enterprise Architecture is a big fat joke and has only been successful at realizing adding spending, not enabling our strategic intent and removing consistencies. Ruby will only show up in enterprises were they don't determine their own destiny.

3. Much of the guidance that the enterprises receive come from either big consulting firms such as Accenture, DiamondCluster, Wipro, Bearingpoint and others. If it isn't on their radar then it probably won't reach critical mass. Likewise, the other perspective comes from industry analysts who usually make irresponsible recommendations and oversummarizations of most problem spaces. In this particular scenario, industry analysts aren't even wasting their own time talking much about Ruby. If you happen to see Gartner or Forrester establish a conference on Ruby then it will catch our attention, otherwise we will not pay attention.

4. How many enterprise architects do you think that work for Fortune enterprises are actually reading the magazines that to date have discussed Ruby? A very small percentage. They are too busy thinking about the strategic intent of their own enterprises and many of these magazines are losing their focus and direction by providing a vehicle of meaningful content. Many of us in this space now get our information from each other and the blogosphere.

5. Speaking of the blogosphere. Have you ever ran across a single enterprise architect who is employed by a Fortune enterprise blog about Ruby. I believe the answer is an emphatic no (I don't count). In conversations with several of my peers at work, many of them have used Ruby for outside projects but when asked why aren't they championing it at work are of the belief that there are simply more important issues to talk about. Ruby is somewhere on the list towards the bottom of the pile.

6. Large enterprises tend to like big vendors. Some will be of the belief that it is because they mail us enterprise architects brand new laptop bags with their logos on them (some small truth to this) while others acknowledge that it is all about capitalization. The latter will work itself out over time (or not) but maybe the Ruby community should step up its branding efforts with T-Shirts and other giveaways in places where enterprise folks tend to gather.

7. Those same vendors such as Sun, Microsoft, BEA, Oracle, CA, etc simply can't make money off Ruby. If a business can't make money off it, why would they even care. I am somewhat glad that folks at Sun aren't paying much attention to Ruby as it is important for them to focus on making money and they do so on Java.

8. Enterprises no longer really care about productivity (describing in terms of extremes, so don't take literally) but are more interested nowadays in transparency. With all the legal and regulatory issues affecting many large enterprises the focus has simply shifted away from software development oriented issues to other areas. Saving a couple of developers a couple of weeks on a project can easily be wiped out by a single subpoena from an attorney general and all the legal fees one has to spend.

9. The community needs to get their priorities straight. People, then process then tools in that order. Ruby is a tool. We know of at least one analyst that gets People over Process is what matters. A fool with a tool is still a fool.

11. The productivity argument is lame. Do you know how many times my phone rings in a day with some poorly trained sales guy on the other end attempting to sell me something? Do you know that all of them talk about productivity gains? If any of this were ever true, I would be the only person in IT for my company. We know that productivity simply isn't realizable in the way folks are calculating it.

12. Back to the books, all those books that won the SD Magazine awards are somewhat dishonest. Is it stated somewhere that this award is one that folks pay for? Let's add some transparency which will bring the community credibility.

13. Lets say there is a sixteen week project and the productivity stuff was true and Ruby could save me an entire three weeks which would be significant. Since Ruby is a new vendor and not represented by existing vendors I already do business with, do you think that I will spend more than three weeks in just negotiating the contract?

14. I am one of the biggest supporters of agile methods but I too am not so delusional to know that many of its founders don't practice transparency. One should immediately question folks in the community regarding Ruby and attempt to figure out what's in it for them. Likewise, it would be wonderful if these folks became more transparent on their own. One of the original members of the agile community that I have tons of respect for is Jon Kern. You may have noticed that he doesn't talk much about writing code but focuses in on generating code and is a big advocate of Model Driven Architectures. The future state says that coding will be for the lame and that code won't matter but I guess the agile community didn't get Jon's memo...

Big used to matter. Big meant economies of scale. Big is the egos of many enterprise architects in corporate America. Big is now a predictor for failure...



Big computers in your data center are silly. They use lots of power and are not nearly as efficient as properly networked pizza boxes (at least that’s the way it works at Yahoo and Google). Big boom boxes are replaced by tiny ipod shuffles. Big budgets for anything results in even bigger budgets until things grow out of control.

If you have ever attended a presentation on service-oriented architectures by any of my coworkers, you may have noticed how we eschew big budgets for SOA. In fact, there is nothing in the budget labelled SOA. Likewise, when architects collaborate and figure out the next minute architecture, we do so via face-to-face discussions. No big meetings, corporate policies or feasibility studies. Just do it...



The principles of the agile manifesto encourages frequent customer interactions. Being close to decisions that matter allows one to make them quickly. If your customer has questions, you can provide not only the answer but insight into how they can think even deeper. The larger the problem, the harder you have to work to make things smaller.

Staying small requires one to outsource in a way that is not evil. Embrace outsourcing for all the boring, low ROI work which allows you to focus on things that matter. Command and Control almost always results in big inflexible decisions that result in the wrong decision being made...