Enterprise Architecture: From Incite comes Insight...

I am a big fan of Secure Coding Practices and believe that all enterprise architects should take the time to familiarize themselves with their goals as it can provide immense benefits to the enterprise, yet I also believe that its potential success is constrained...



Generally speaking, many enterprises are buying more software than they are building themselves which tends to result in an imbalance of power. Doc Searls in his blog talks about Vendor Relationship Management as a method to bring back balance but in terms of secure coding practices it may not be economically viable to do the job right.

Us IT types are great at using analogies with a frequent term being the notion of a warranty period. In all reality, this is more about generous after-sales support and not really about avoiding defects in products at development time. If one ever studied the economics of the auto industry, you would notice that car dealers make more money on after purchase services than they do in selling vehicles. I believe the same thing occurs in software.

I previously blogged about the cost of sales in terms of a closed source model where in all reality enterprise architects complain about the cost of software at procurement time without understanding the total costs over the long haul. If a vendor makes money by forced upgrades and in telling enterprises that they must upgrade by a certain date or lose support, then why would they write software correct in the first place? When it comes to software, more bugs means more support and an opportunity for sales folks to sell upgrades.

Maybe the problem is that enterprises keep getting it twisted when it comes to having incompatible goals where out of three choices of cheap, time to market and high quality, and they only get the choice of two, the last one always suffers. I am of the belief that in order for secure coding practices to stick, enterprise architects need to educate the business community on how to create requirements around security. I suspect that within most enterprises, other than receiving a statement such as I want my software to be secure and we should use existing products, that no more thought has went into this important topic.

Likewise, enterprise architects would be well-served by engaging the process weenies who are in love with metrics and getting them to figure out a way to quantify that the real issue is not that we are not spending enough money on software, but that we are not developing software in an appropriate manner.

Was thinking about why enterprisey folks tend to eschew languages such as Smalltalk...



Everyone has their own religion in terms of static vs. dynamic languages but the simple fact remains that there is a strong preference towards languages that do static typing. Some will be of the belief that this is a historical trend coming from the likes of COBOL and therefore Java is familiar in terms of the paradigm, however I believe something else is at play.

Statically typed languages work better for the masses of unmotivated programmers that fill the corridors of large enterprises. They desire for computers to catch their mistakes. Likewise the notion of any enterprise caring about individual productivity of their developers is long gone. If enterprises continue to outsource to places such as India where folks may have lots of academic credentials but otherwise are horrific at software development (overgeneralization) then the ability to at least ensure that the code when it comes back that it can compile becomes crucial.

Several weeks ago, I ran across an architect that works for a large enterprise down the street where he shared with me some interesting politically incorrect statistics on their relationship with their outsourcing firm. He has been privately tracking the amount of code they receive on a daily basis that simply won't compile. It would be intriguing if other enterprises not only captured these metrics but started to share them publicly with others.

Anyway, Dynamically typed languages do require better developers than statically typed languages. If you take a dynamically typed language such as Smalltalk and put it into the hands of someone competent then you will end up with something better. Likewise, if you put it into the hands of the average corporate software developer, it is a prediction that you will end up with a mess.

Have you ever considered how many enterprise applications would break if Garbage Collection wasn't of high quality within Java?

The best architectures, requirements, and designs emerge from self-organizing teams yet the opposite principle is built into the organizational models of large enterprises...



Since someone needs to be the boss, why not make it the enterprise architecture team who can then be empowered to mandate best practices. Don't get it twisted and take this serious. The blogosphere though needs to stop talking about nomenclature and start talking about solutions. I wonder how many enterprise architects when they meet with their bosses ever talk about:

• Changing the culture so that self-organization is a fundamental principle


• Achieving a purpose without the need for a leadersmanagers direction


• How to focus on people, then process, then tools - in that order

I have always found it curious to work in an industry where we have an estimated failure rate of 50% yet we get paid more than many doctors, teachers, accountants or other professions where failure is not tolerated...



Working in an IT organization is easy but becoming an IT professional is more difficult. During the dot-com era, we let graphics artists into the IT organization which helped inflate their salaries. Likewise, Project Management whenever it resides within IT, the salaries tend to be higher than when it resides outside of IT. The funny thing is that the discipline of project management really isn't all that different regardless of being applied to IT, the building tract houses in construction or even managing a multi-faceted marketing campaign.

Early IT folks have managed to trick the rest of society into paying more than what its output is worth. I have heard enterprise architects in other shops perform a ceremony where they appease the business side of the house and appear subservant to business folks who while having more power actually make less than them.

The one thing that I have figured out is that there are simply way too many folks doing software development which results in creating way too little economic or social value which results in being highly compensated for doing pretty much nothing of value. Likewise, there are a lot of folks who produce a lot of value who are on par in terms of compensation with those who don't.

Would our profession be better served if we could discover the correlation between output value (productivity) and the recompense of the range of salaries of IT professionals? No, I am not advocating that we find our justification in the fact that there are folks worse than us. We need to as a profession figure out how IT needs to evolve so that we can produce a dramatic shift in the value we bring to the table.

I have always wondered if aligning with the business is the right mantra. I guess the problem I have with this phrase is that the business for the most part stays stationary while IT does all the changing. If we were to acknowledge for a second that the vast majority of business folk are fundamentally uneducated about the basic facts of IT and we were to figure out how to get them to align with us more in the know, could this then be the stimulus for providing better correlation between output value and compensation.

IT enables capitalism yet prevents it in the same breath. We will all rant if the top 1% of all Americans become even richer while the majority languishes in relative poverty without really understanding the forces at hand. Would it be good if IT were to maximize its efficiency so as to create an upper eschelon or would this be evil?

William Edwards Deming assumed that a system can't understand itself. Therefore, he needed a tool that provided a way of looking at and understanding organizations...



Profound Knowledge is the tool that solves for this problem space and consists of the following parts:

• Appreciation for a system: Understanding the organization as a system.


• Knowledge of variation:Seeing variation as a normal behavior of a system.


• Theory of knowledge: Promoting a culture of learning and continually improving way of working.


• Knowledge of psychology:Understanding that the system affects the behaviour and performance of people.

Appreciation for a system means that you view the organization as a system of groups, processes and components working together towards the purpose of the organization. Subcontractors and customers are also connected to the system. Every part in the system is dependent on and influenced by all the other parts. Thus the performance of a part must be judged from the perspective of how it contributes to the whole system and how the system facilitates the performance of the part.

Knowledge of variation. Variation is a fundamental behavior of a system, especially systems containing people, such as organizations. One has to measure the performance of the system and determine the variation. Then you can take measures to reduce the level of variation in order to be able to better predict the future performance of the system and to increase quality. Knowing the normal variation also enables you to identify special cases not caused by the system.

Theory of knowledge. A culture of learning with a team approach to change should be installed in the organization in order to better cope with external demands and adapt better to new ideas. The organization continually improves its structure, processes and methods. It also involves and encourage others in making these improvements and to transfer knowledge. This should be done in a planned and collaborative manner. The continuous improvement and learning activities of the organization is not only directed towards higher quality but also toward being more responsive, adaptive and effective.

Knowledge of psychology. The people in an organization (i.e. a system) especially managers must realize that the system affects the behavior and performance of the people in that system. Blaming people for errors induced by the system is counter-productive. Instead, the errors should be removed by improving the system. Employees should feel pride in their workmanship and true satisfaction from their contribution. The causes of fear have to be driven out and artificial barriers torn down. Intrinsic motivation is the only sort worth having.

Does maximizing shareholder value require treating employees well?



if doing so is necessary to retain employees capable of boosting shareholder value; otherwise the ethical thing to do is outsource, terminate, and exploit. Maybe folks have gotten it twisted as to what ethics means in a business context. Real business ethics is an ordered list of concerns:

• Employees (most critical to corporate health)


• Customers (secondarily critical)


• Creditors and Financial backers (Least critical and also least involved)

You may also note that in situations of bankruptcy, the list is the exact opposite. For folks who want to increase the perception of business ethics then the best way to do so is to become stockholders. If employees are the primary shareholders and they can get rid of non-participating outside shareholders to the fullest extent possible then the perception of ethics increases dramatically.

Gerry Gebel of the Burton Group discusses the need for an Interoperability Challenge and asks questions such as can enterprises really mix and match policy administration points and policy enforcement points from different vendors? Is the XACML RBAC Profile practical?

This feels like an opportunity for BEA, Vordel, CA, Oracle, IdentityEngines, LogLogic, Securent, IBM, OpenID and Sun to show interoperability at the XACML PAP and PDP layers while the likes of Intalio, Alfresco, Liferay, SugarCRM, Compiere, ServiceMix, Sonic, Documentum, Filenet and Microsoft all demonstrate their upcoming support for XACML PEP being incorporated into their various product lines.

I would especially love to see Gerry talk about the limitations of identity management tools and how entitlements approaches can compliment them. Hopefully, he could get the likes of Dick Hardt, Johannes Ernst, Pat Patterson and Conor Cahill to also talk about the role XACML could play within a federation...

Have you checked out SpamBayes? Some of its features include:

• More sophisticated trapping of "word salad" spam -- i.e., email containing nonsense phrases or gibberish -- to disguise an image attachment that contains the actual spam. This has become a fairly major variety of spam, and not easy to filter.


• Looking for the presence of Habeas headers to determine if email is valid.


• Experimental support for image extraction and optical character recognition (OCR) to determine if images contain textual spam (also known as the "crack-images" option). This option relies on the ocrad and Python Imaging libraries and is only being minimally supported at this time; there's controversy about whether this is a valid way to handle the problem.


• Many small fixes to the Microsoft Outlook plug-in.

The funny thing is I suspect that most spammers will download this software before end-users...

Leisa Richelt asked here about the lack of women on the speakers rosters at conferences with an equally passionate discussion started by Jeremy Keith here. I wonder if this is an opportunity for bloggers to stop exercising their right to remain silent and start drawing some attention to this issue?



Maybe folks in the Agile Community such as Martin Fowler, Kent Beck and Jeff Sutherland could start championing this cause? Likewise, Tim O'Reilly could do so in Web 2.0, James Robertson in Smalltalk, Phil Windley in Identity and Bruce Scheiner in Security could do the same.

Maybe even the industry analyst camp could figure out ways to get wonderful industry analysts such as Anne Thomas Manes, Anne Zelenka and Brenda Michelson to speak at more conferences and get quoted in the press more...

I recently updated the template for my blog to include books I believe will benefit the careers of enterprise architects. Tell me if I my list is good enough...

There are few individuals in the blogosphere more thoughtful than James Tarbell. When he posted Architect Like You Are Retiring I thought it was absolutely brilliant yet I still can't refuse my urge to critique...

Architect with a plan to not be critical path to understanding its elegance or complexity or style. This is a derivation on Keep It Simple Stupid.

Agilists believe that plans tend to be static and therefore refer to planning. It would be interesting to understand how not to be on the critical path as this phrase is very fuzzy and probably has more to do with perception than reality.

Design so that the brilliance of the solution would beg the company to hire you back after retirement to consult at twice your pension

It is difficult to know if brilliance is serious or sarcastic. Many IT folks create "legacies" so that their employers become heavily dependent on them. I suspect many consulting firms train their employees to do so regardless of retirement.

Design in a way that values people before process or technology such that people will miss you and invite you to subsequent years Holiday parties.

Sometimes being a good architect requires tough love where folks will appreciate your contribution but may not appreciate your presence...

Architect with realization that the security of your future pension and profitability of your company stock is based in some part to the efficiency and appropriateness of the costs of your design.

Noble thinking that isn't backtestable. Architects should care that the stock price of their former employer goes up but this really isn't 100% correlated to expenses. A great CEO can have a rising stock price and declining profitability if he manages surprises on Wall Street. I would challenge anyone in the blogosphere in terms of ethics which one would they choose a) Better design that lowers TCO by 20% year over year and you get indirect benefits from stock price increase b) Less optimal design but you had great fun creating it and even got your boss to give you a big freakin bonus but long term TCO increased. Reality says that how folks are measured and compensated seriously needs to be revisited.

Workwith a realization that your likelihood of getting a good pay increase (which could later translate to a better pension) is based on your ability to

Pay increases are also tied to being in the right place at the right time, supply/demand pressures, and your worth according to recent salary surveys.

If you have taken any of my responses to JT's posting seriously, you are definetely getting it twisted. I wonder if he could in his next blog entry, think about the notion of blogging like you are retiring...

Stowe Boyd is seeking information that will make a solid case for blogging as a strategic benefit. Lately, my own thoughts have been to discourage folks in large enterprises from participating especially if they work in IT.



Most folks are incredibly busy and do a lousy job of maintaining work/life balance and blogging will further move them away from it. Consider what happens when an Enterprise Architect decides to openly share information with the community at large on some wonderful open source project that they believe is of high quality. What happens if the open source project competes with commercial closed source products already owned by the enterprise? Do you think that this individual along with his/her peers will not be bombarded by sales folks demanding more of their time?

Consider the fact that external conversations do have an effect on internal conversations and how this too changes the dynamics of work. Many corporate folks are successful because they pay attention to internal conversations so that they can always be in the know. Once conversations start occuring outside the enterprise, many folks lose their ability to observe them which can change the dynamics in a dramatic way. Sometimes, this can be good or bad and is heavily dependent upon the personality quirks of the participants up and down the foodchain.

Have you ever been in a situation where you shared something with others because you were genuine in wanting them to be successful yet they perceived that the only reason you were doing this is because of some ulterior motive? I doubt a month, a week or even a day goes by when I don't run into this phenomena. Part of the dilemma is that for the most part the sole reason everyone else is blogging is that they are attempting to sell something. Analysts are attempting to sell influence, software vendors are selling support and products, consultants are selling their services, but when someone from a corporate environment shares, folks may also be cast into the same bucket.

The rationale of why I blog is simply to be a good citizen and share my perspectives with others in hopes that they can avoid many of the pitfalls I have encountered. I guess at some level, I would like to sell the need for us to be more charitable towards each other as my blog has many wonderful opportunities to contribute, but for the most part I have failed miserably at this as none of the charities have received a single cent from any of my readers.

In the world of venture capital, the notion of the exit is discussed with passion. Before corporations start blogging, they need to also figure out when to stop blogging. For me, the answer became crystal clear. On the way home as I pulled into my driveway, on the radio was a old hip-hop song that talked about power:

Don't say this, don't say that, change the lyrics. Everybody's a critic, it's getting kinda hectic...

For me, my anticipated exit from the blogosphere will be April 1st as blogging has become more pain than joy. When one spends more time, managing conversations and the perceptions that emerge rather than having more conversations, one can consider themselves travelling deeper into a black hole.

If there are folks reading this who are employed by a corporation that desire to blog, I would recommend to you to avoid several mistakes I have made. First, in terms of blogging, I should have came out of the gate anonymously. Sure, if I were say Architect742 and not myself, there would have been less credibility but likewise it would have been a whole lot easier in terms of pain I have experienced. Being anonymous would have also allowed for better separation between my blogging at home and work which I attempt to maintain a firewall between yet others attempt to always penetrate it.

My second recommendation is that folks should never blog at work, about work, nor even from a blog hosted on a work domain. The idea should be sharing and not about branding. In terms of Stowe's thinking, I suspect he would recommend corporations to blog as a matter of interacting with a larger community. The hard part is that communities in the blogosphere are self-selecting which makes it incredibly difficult to have a meaningful conversation and everything digresses to keeping things at such a high-level as to be useful only to a select few.

In all reality, maybe I won't really retire as a blogger as I will still need an outlet to share. Maybe I am like the Phoenix and will destroy duckdown.blogspot.com and reincarnate myself at some future point in a more anonymous way...

Jeremy Miller classified folks when it comes to coding philosophies into two general camps...

• Camp #1: Coding is too hard, so let's not write code anymore. Model Driven Architecture, Executable UML, Business Rules engines, BPM, Rapid Application Development


• Camp #2: Coding is too hard, so let's make coding easier and more productive. Refactoring tools, dynamic languages, TDD, Continuous Integration, Ruby on Rails, etc.

I am definetely in the second camp as I haven't yet drinken the Kool-Aid on most things in camp one with the sole exception of Business Rules Engines. I guess enterprise architects who are in the second camp are a dying breed and are the ones blogging in the blogosphere while the former camp are the ones who are successful getting promoted in today's magazine-oriented architecture culture.

Whenever one describes things in terms of extremes (camps), someone sooner or later comes by with the hybridism pattern and totally misses the point. Anyway, I wonder if I am still relevant, in the wrong profession or simply need to get with the program...

The folks over at Redmonk have recently published a wonderful research paper on Open Source ESB that is definetely worth your time to read...

Industry analyst Alex Fletcher commented on the lack of honesty amongst open source vendors when it comes to things such as dual licensing, adherence to OSI definition and other sins. There is one thing he said that is troubling:

I'll avoid naming any names not due to any conflict of interests with Entiva, just out of common courtesy)

Here is how the problem starts. Large enterprises spend money with industry analysts to gain insight and guidance. Our decisions will be less informed if industry analysts won't tell us the honest truth on a dimension that could be important to us. While we understand that lots of industry analysts derive their revenues from vendors and not customers, it is at least somewhat important to be more transparent in this regard.

I am of the belief that small industry analyst firms moreso than the large guys have a fidicuary duty to provide this information and name names. Consider this could be a selling point that the big guys don't offer. If you also won't name names then why should I consider purchasing your services?

I wonder what it would take to get James Governor of Redmonk, Raven Zachary of the 451 Group and Alex Fletcher of Entiva to not only name names but to publicly guide this firms towards the light and help them truly understand the benefits of having an open source business model that is compliant with all the definitions...

The other day, my family and I ate lunch at It's Only Natural an organic restaurant in Middletown, CT that was absolutely worth the trip. While slamming down a vegan Hazelnut Chocolate cake where we listened to an IT executive (You can tell by the suit he was wearing, his vocabulary and his lack of understanding of technology) rant about the buzzwords used by outsourcing firms to our amusement. He stated how one of his business peers stupidly smiled everytime the outsourcer used the word quality in a sentence. This begs the question of what does quality mean to folks...



So, exactly what is quality when discussing software? I am of the belief that it supports the below five principles:

• The code compiles and executes - Sorry to state the obvious, but I suspect lots of folks have received code from outsourcing firms that didn't


• The code implements all the desired business functionality without frivolous stuff


• The code is not duplicated - aka copy & paste programming


• The code is self documenting and doesn't require a manual or other heavy enterprisey-like document in order to do something useful with it


• The code can be easily extended by folks of average ability in a timely manner and without grief on the part of those senior to them

Noticed I avoided usage scenarios or anything that sounded like an endorsement for non-functional requirements (aka system qualities)? In software, there are at least two broad categories of uses; the user of the running software (the user's use) and the use by programmers in an attempt to make a different version of the software (the developers's use). A useful program that's impossible to modify has high-quality in the first category but not the second; a highly habitable program with a geeky user interface meets the second but not the first.

I also didn't mention aesthetics which I haven't quite formed an opinion on. Code shouldn't be considered a thing of beauty or a masterpiece but it should have style in terms of good spacing, indentation and formatting. At some level, high quality code is dependent upon having high quality processes. Afterall, business folk doen't get to see code (unless they ask in a really nice way) but they do see process and therefore this becomes more important. High quality code is the result of high quality design which is the result of high quality processes.

NOTE: CMM ensures that processes are repeatable but doesn't guarantee that the chosen process is of high quality. I suspect this is where CIOs fall into the trap...

Can we acknowledge that quality occurs at a cost? Otherwise, folks would be doing it all the time because higher quality provides higher satisfaction amongst employees who contributed to it. Likewise, with higher quality comes higher costs. Folks need to be continually trained in best practices which no one seems to talk about nowadays. When a new technology comes along, it is costly design a quality process around it along with morphing other practices that are no longer best.

If you intend to be in the game for the long haul, then quality matters. Nowadays, software firms have been trained to think about the exit while corporations answer to the quarter. I am not sure if IT still matters, but I know that quality in IT doesn't...

Several years ago, I was on a quest to find a mentor. While attending an event where Ron Williams, CEO of the Aetna was speaking, I saw someone across the room that I determined should be my mentor. Upon crossing the room, I bumped into another executive (who is now retired) whom I struck up a conversation with. He gave me two pieces of wisdom with the first being make sure that you don't get a mentor that exhibits the same traits as you (e.g. nationality, age, profession, etc). The second thing he suggested is that I need to be vigilant in seeking out new perspectives...



Since this event, I have had two mentors. One currently is a high-level executive on the business side for my employer while the second works in IT for a Wall Street firm. Both have given me wonderful perspectives and taught me things about myself that I otherwise wouldn't have learned. For each of this individuals to spend a couple of hours a year, I am eternally grateful.

In the same way employers who practice diversity are wildly successful, so should I. In my career, I have never had a mentor who was female (my original target was) nor anyone born outside of the United States and therefore would like to solve for these two characteristics.

The funny thing is that the principle of six degrees of separation isn't quite in my favor so I must resort to cold calling. Right now, I was thinking about asking Farooq Kathari who is CEO of Ethan Allen, Azim Premji who is CEO of Wipro or Stanley O'Neal, CEO of Merrill Lynch to handle one dimension of diversity while also pinging Carol Ann Petren, EVP and General Counsel of Cigna, Meg McCarthy, CIO of Aetna, Cheryl W. Grise, EVP of Northeast Utilities or Dona D. Young, CEO of the Phoenix for the other dimension.

Any predictions of whether I would be successful reaching out to these individuals?

new vulnerability in Snort, an open source intrusion-detection system, enables hackers to inject hostile code into exposed systems. The primary flaw which was discovered this week is in Snort’s DCE/RPC processor, which is vulnerable to stack-based buffer overflows.

It is intriguing when security products themselves are used for attacks. This hints at the fact that the problem of getting the IT community at large to embrace secure coding practices is futile. I wonder if the folks over at Ounce Labs, LogLogic and Fortify Software can help?

I ran across the Open Solutions Alliance which pretends to represent the spirit of open source. I wonder what it would take for industry analysts to start providing guidance to large enterprise customers who are confronted by vendors who are less than noble in embracing open source...



Let's first analyze the licensing agreement:

You may use, copy, modify, and make derivative works from the code for internal use only. You may not redistribute the code, and you may not sublicense copies or derivatives of the code, either as software or as a service.

Does this feel open to anyone? How come they are twisting the official definition posted here? You may notice that real open source is always available to anyone, at anytime for any purpose and that the user is always licensed to modify and redistribute the software with fee, penalty or the need to ask permission.

I know it would be difficult for industry analysts in the open source community such as Raven Zachary, James Governor or Alex Fletcher to ever call out vendors who are not really open but purport to be. It would be interesting though if someone else in the blogosphere did...

In a previous blog entry, I comments on the biggest myth in Project Management but of course, I managed to think of something equally evil practiced within many enterprises. Both JP Rangaswami and Todd Biske both commented on why EAs aren't embracing agilism. I figured it that if I combine these two thoughts, then folks may realize some EA antipatterns not previously discussed...



Both JP and Todd have discussed applying the Agile Manifesto to enterprise architecture. One of the things that shops who attempt to embrace agile approaches almost always fail at is in the elimination of time tracking. Of course, the bean counters and even the business wants to understand their investment spend within IT, but I savagely believe that what they are asking for is different than what they really need.

The business asks for hours while developers simply don't care to track them and therefore pollute the metrics by simply making the dialog go away. Developers on the other hand, understand that they do care about whether the tasks assigned to them are complete or not which is also in alignment with the business requests for information.

The business doesn't really want to know about time but they do want to understand velocity. Velocity should be a predictor of outcomes and of courses acknowledges that trajectory sometimes changes. Over time, velocity stabilizes within a project context which also provides another useful metric that time capture doesn't.

Could enterprise architects make things better for software developers if we displayed an ounce of courage and rebelled against time tracking? Emphatically yes! Imagine what would happen if developers solely worked on software development and could spend more time improving the quality of software instead of participating in distractions us enterprise architects, process weenies and bean counters force upon them...

I would like to thank John Newton for providing feedback on my blog...



Here are some of his thoughts along with my reactions:

Use Britney Spear’s bald head as a metaphor for the decline in morality of traditional enterprise software vendors. Use Anna Nicole Smith as an object lesson in the excesses of greed and investment in new, shiny technology.

The funny thing is that I can't really attack the morality of traditional enterprise software vendors as it pretty much mirrors the decline of morality within IT at large. As far as Anna is concerned, the notion of overweight architectures does fit nicely.

Your blog disassociates itself from your employer, but that shouldn’t prevent your from presenting use cases that we can actually use to build product

Part of the disassociation is in managing vendor expectations. Do you know how many calls I get in a week where a vendor salesperson has read my blog and will immediately want to associate it with work? This causes not only a productivity headache as this takes away a lot of time on focusing on more important problems but likewise results in sales folks also blowing up my coworker's phones if I am not so fast in returning their calls. I have a strong desire to keep my day job disassociated with my blog for a myriad of reasons, but this shouldn't prevent me from sharing use-cases. The only thing I ask is that folks read it, without reading into it.

Since, you asked for use-cases, how about the five I am most passionate about in the security space. The first is that nowadays, no enterprise application should ever create its own credential store. It would be difficult to find a Fortune 1000 enterprise or the international equivalent that doesn't already have Active Directory. How come you can't simply bind to it at runtime and allow attributes to be mapped to the various parts of the tree?

My second use-case is that we all understand that ECM products usually are useful in conjunction with other technologies whether it be ERP, ECM or CRM. Shouldn't it be reasonable to have out of the box support for SSO based on industry standard protocols such as SAML, WS-Federation, SPNEGO, OpenID, etc? For a third use-case, you may have noticed lots of discussion in the blogosphere regarding identity management yet I haven't ran across a single ECM platform that is identity-management enabled. Support for the Oasis SPML specification would make sense here. Finally, support for compression and encryption should be built into the product but should only be done using open algorithms. Proprietary compression algorithms especially when they are closed source is ugly. In terms of encryption, don't think shared secret as no one is good at keeping them. Minimally, start noodling PKI where key escrow is externalized with the end game being the embracing of identity based encryption. Check out the offerings by the folks at Voltage in this regard.

For the fifth and final use case, I would really love to see ECM vendors start incorporating XACML support so that enterprises can externalize fine-grained authorization. Some folks aren't exploring this because they have rationalized that this would be too slow. Nothing is further from the truth. Open source Portals such as Liferay can be cleanly integrated into an XACML solution because the underlying design is clean. In Liferay, all you have to do is extend a single class PermissionChecker and you are enabled. Lots of folks have written horrific authorization code that isn't centralized which causes vendors to pretend that the problem doesn't really exist. NOTE: I haven't checked out Alfresco's source in detail in this regard to know if the problem exists or not.

As abstractly as possible, what are the application domains that you are tackling and what role does new technology, such as some of the new Web 2.0 like AJAX, REST, tagging, etc. play

You will find all of these technologies at play. There are several reasons why I tend to not speak about them. First, I don't really find they are worthy of writing about as others have already hyped them up. Second, a good enterprise architect should first leverage what they already have instead of chasing the hype of the minute.

You have blogged some good things about open source, but where are you actually use it? Where do you draw the line of open source vs. traditional?

Usage of open source vs. traditional models is something that my coworkers already talk about in public forums along with bringing an enterprise perspective on them. If the blogosphere at large wants to have a deeper conversation on this, I would suggest pinging all those conference chairs and getting them to get my peers on panels to discuss.

You posted an article on user advisory boards. It seems to me that blogging may be a more potent form of user advisory board. How about trying a user-led versus vendor-led user advisory board organized through the blog

There is one form of advisory board that I tend to talk about more than others which has to do with the venture capital community. The investment models used by these guys is so disconnected from what we actually desire. It is intriguing that there are problem-spaces that large enterprises have had for years, yet the VC guys aren't even paying attention. I would like to solve this aspect first.

The second aspect of advisory boards is that they are not just useful for vendors to listen to customers but for customers to talk to each other. Consider that within the blogosphere, you will find lots of folks blogging on enterprise architecture but for the most part they are all employed by consulting firms. I only know of five individuals in the entire blogosphere that are directly employed by a Fortune 100 enterprise. No one to date has figured out a way to get enterprise architects to blog, so there is still value in traditional conversations.

Write about how you find time to blog - this is one of the hardest problems that I have

Believe it or not, I really don't spend a lot of time blogging. Remember, I don't have the overhead that vendors and industry analysts have in terms of making sure my external communication is as polished as it needs to be as I am not really selling anything. In terms of topics, I have my own thoughts along with wonderful conversations I may have with my peers in other organizations, so ideas are plentiful. I also can type 85 WPM and have been able to since high school. I figured out at a young age that was where all the girls were. Anyway, I spend about 15 to 20 minutes a day blogging so time isn't really a factor.

Some insight into your purchase process and purchasing decisions - very important for vendors

Reading into your question, I know you are not really asking me for contact information for folks in procurement but really want to understand the thought process behind the scenes. The problem is that it varies depending on size of spend, whether the product in our mind is strategic or tactical (don't ask me to define as this is a rathole), the players involved (Business types, architect types, process weenies, etc), whether industry analysts have deep coverage in terms of research, the latest opinion of magazines along with indexing as to what industry peers also think. There is no one great roadmap that I could provide to make navigation in this regard easier.

My blog on your blog roll

This was an oversight on my part. Thanks for pointing this out...

A post about how you are going to buy a lot of support for Alfresco

Which would be better, a one-time post about how I am going to buy lots of support or a posting at least once a month of me encouraging my industry peers to download and evaluate Alfresco as the sole solution for the ECM space? Wouldn't it be better for me to be the first person blogging on the fact that Alfresco is the only ECM vendor that nailed all of the security considerations previously outlined and on top of it, embraces secure coding practices where they formed a deep relationship with Brian Chess from Fortify Software?

Below are two blog entries by others that are worthy of amplification:

• Enterprise Architecture Management Styles


• Architect, Functional and Technical: IT's Good, Bad and Ugly?

You may note that both are from the UK which has a country filled with wonderful enterprise architects who in many ways are better than what us Americans are capable of producing...

Ishmael Ghalimi commented on what's wrong with BPM. I figured I would critique his posting...

I challenged my friend and industry analyst Bruce Silver to point me to a BPM vendor that could identify three customers who successfully managed to use its product to build a complex business process that would leverge a Service Oriented Architecture, and managed to do it without writing code and with no technical support from the vendor. He could not.

Ishmael, this feels like a problem that isn't exclusive to vendors. I suspect that many enterprise folks aren't receiving adequate training on BPM in order to be successful. Do you have a sense as to whether the marketplace has the right books, conferences or other methods for learning available or do we need to address these deficiencies too.

You want to connect to a web service through WSDL? Well, this will require some code to be written, some files to be packaged, and debugging will keep you busy for quite some time. Could you use the sexy process simulator for process debugging? Forget about it…

OK, how come all BPM vendors can't simply get together and come up with a simple shape to describe this without writing code? Maybe, Intalio could show other vendors some leadership by writing it for them and allowing them to include it in their product. Of course, ego would get in the way if this secret were to leak.

While getting a process to call an external service (outbound call) was doable, getting an external service to call a process (inbound call) does not seem to be part of the offering, and you need to implement your own listener as a Servlet for it to be done. Nice…

This feels like another opportunity for BPM vendors to collaborate and develop a common way to make this happen. Maybe you could sketch out something REST-oriented that is generic enough for all products to implement.

leading to an alarming failure rate for BPM projects that go over time and over budget in most cases, and an abyssmally low level of repeat sales—same customer buying again from the same vendor.

Hmmm. This feels like a failure on the part of industry analysts to ask tough questions. Maybe they need to track more metrics on repeat customers and not just focus on revenue growth.

In general, it feels like a big problem in enterprises who spend $300K to buy magic pixie dust is the same with any new technology in that they may not know what questions to ask. How about coming up with a proper RFP that shows enterprises how to become smarter. Most of the guidance provided by industry analysts in this regard is lightweight. Did you ever ask Bruce Silver what he could do to help customers avoid this problem?

Interesting article here...

Have you ever had the experience of answering a seemingly simple question but it really wasn't...



Here are questions to ask folks in India:

• What CMM Level is the Software Engineering Institute?


• Outsourcing is attractive not solely because of the phrase: "We work cheap" but also because of the banner of "We will conform" and "Anything you ask, we will do". If India no longer stays cheap, do you think that the other aspects still matter?


• Do Indian software developers have a choice in terms of embracing lighterweight agile approaches on their projects or are they forced to do everything waterfall?


• How come folks that are employed by large outsourcing firms don't blog? Will you be threatened by others for showing knowledge or lack of?


• Do you see staff turnover increasing? Does the quality of work folks send to you have an effect on this metric?


• What are some of the stupid things customers continually outsource that they shouldn't?

NOTE: I suspect that most will exercise their right to remain silent or respond anonymously...

I am seeking genuine feedback on how to move this blog from good to great...



I'd like to start an "open mike" discussion via trackback that I have been wondering how to raise for awhile now. I'm interested to hear from bloggers of all varieties (folks in corporate America, software vendors, industry analysts, the open source community, those employed by outsourcing firms etc).

• What tools do you use to read my blog?


• Are there topics that I should blog more about?


• Are there topics that I blog about that are simply annoying and should stop?


• Is there anything you would like for me to share about my background?


• What visual changes would you suggest I make to this blog?

Working late is usually more visible and will therefore get you further than getting in to work early...



Last week, I had phone conversations with two Enterprise Architects, one in Chicago and the other in New York in which I discovered an interesting pattern. It seems as if these two individuals are being pushed to work longer hours to make up for the shortage in resources. Instead of complaining about complaining, I asked them to instead understand what the shortage is all about. Consider the fact that a large percentage of waste that goes on in our profession due to insane schedules, badly defined products, faulty methodologies, lousy tools, boneheaded ideas, etc. (not to mention websurfing to track our stock market investments) we may actually have a surplus of people who are badly used.

In thinking about the best way to solve for the problems that enterprise architects face, maybe they are missing out on a big opportunity for improvement. What if they championed the notion that the work week should be limited to just 40 hours or even less! This would allow for some time for reflection and we might discover that half of all software projects are totally unnecessary, and that the remaining half can be easily handled in the normal work week by existing staff and we can eliminate the need to outsource.

I suspect that a lot of enterprise architects will read this and agree, yet will also not take it any further. Us enterprise architects are really a bunch of cowards. We bitch and complain about long hours on one hand but revel in how hard we work on the other. We need to get off the fence and start taking control of the destiny of our architectures as stewards. I bet not a single enterprise architect has ever considered providing facts to the IT executives within their world as to how to optimize the number of hours an employee works...

social network named Trusted Opinion came out of private beta over the weekend. The funny thing is that when you go to register with a zip code that starts with 0, it tells you that this is invalid. Even though it is out of beta, I guess it is still beta...

I haven't yet ran across a single enterprise architect that will openly discuss agile methods yet they are all fans in stealth mode. What is preventing us from talking about it within our own enterprises?



Newton's law of inertia states that the larger the mass of a body (n this case, the size and complexity of our employers) the more effort required to move it. Can we conclude that large, bloated corporations filled with procedures and red tape are less nimble, have a harder time reacting to changes in the industry and customer demands? Are these the same enterprises that will abuse the word innovation in order to convince themselves that they really are agile but in all reality there is little evidence of it?

We understand that monolithic thinking is back testable as a repeatable failure yet we stick to it liked being hooked on crack. We pontificate phrases at every opportunity such as plan the work and work the plan while creating methodologies that often look good on paper but once the real world creeps in, it tends to fall apart.

Instead of magazines crying out loud that enterprises have poor communication (which is true) and therefore we need to communicate more and better (which may only be partially true) why can't someone have the courage to stand up and say that maybe we need to communicate less? In looking back when I first got started in IT, in order to get something approved, I only had to communicate to one or two people. Do you think the same headcount applies today?

Why not optimize the organization so as to reduce the amount of folks one needs to interact with in order to get the job done? disproportionately large percentage of the most revolutionary, innovative software created in our generation has been by teams of just a handful of people, sometimes as few as two: Linux, YouTube, Napster, Skype, Bittorrent, Ruby on Rails, Doom, each of of these products were developed by a tiny team of flexible, creative individuals and each one has radically altered the worlds perception of what a software product can do. What prevents us enterprise architects from thinking the same way?

I would love to understand why others aren't talking about agilism as part of their day jobs. Maybe James Tarbell, Scott Mark, Charles Betz, John Gotze, Nick Malik, Robert McIlree, JP Rangaswami and Todd Biske could share their experiences in terms of how frequently they talk about agile methods at work, whether they talk about it to IT executives or only those lower on the foodchain and whether in their travels they believe that executives with a strong technical background is a predictor towards agility...

Ever have someone complain to others about particular features in software that may have wrote but become puzzled as to why no one opened their pie hole and told you directly?



People experience emotional reactions to receiving specific pieces of information, or being exposed to specific ideas. Rather than discuss why they have this fear, and maybe doing something about it, or discussing the information or ideas themselves, they instead choose to project their own emotional state onto some kind of faux "objective" measure, which they promptly use to derail the discussion entirely. It is entirely false, it comes from a position of emotional and intellectual instability, and it is only useful to those who want to hide from reality.

This is called the Head in Sand Pattern. It is not very admirable but is pervasively practiced. One reason this may occur with frequency is that on the other side, if folks don't recognize that people don't believe they have a reason to listen, then may choose not to do so. You can expect certain kinds of reactions from people in certain frames of mind - including the Ostrich Pattern from the listener as well.

Of course this doesn't relieve one of the obligation to say what needs to be said. Honesty is more important than people's feelings. If the truth (or your viewpoint of it) upsets folks, or if they choose to ignore it, then so be it. Does transparency in terms of communications hurt or help build trust over the long haul? Is building trust more important than causing harm to the positive vibes in the short term?

Some say that trust needs to be built which I think is 100% wrong. Children are born completely loving and trusting. They are totally depedent. That have to be taught bad patterns. If you are a manager or a leader (or even don't know the difference between the two) have you ever asked yourself, what bad patterns do you encourage?



Have you ever read Maslow and the hierarchy of needs? At one level, I think it is a logical framework but on the other hand, I think it is also a crutch as it steers folks into a sheeplike trance where the unwashed masses insist on a safer world. What is life without risk and danger? Actually, we do need to eliminate danger is all about personal peril but we should be savage in not reducing but in increasing risk!

Risk is about opportunity. People generally find meeting new challenges exciting. Meeting new challenges involves risk. If you're not willing to risk screwing up, losing, going broke, getting injured, dying, etc then you're denying yourself the chance to experience success, excitement, bliss, ecstacy, thrill, happiness, joy and satisfaction. Would society or the enterprise be better off if we stopped prefering mediated experiences to real ones?

Ever run across a CIO who talks about building software and you know he hasn't ever written a single high-quality line of code in his/her life? Doesn't it feel dishonest? Ever run across a co-worker who talks about how they are building a house when in all reality, they simply called up a general contractor and placed an order. How many of us truly have the skills to build a house? For the record, I haven't ever done one from scratch but have done all the steps after pouring the foundation and framing.

Maybe I should stop complaining and instead go watch an IMax movie on climbing Mount Everest instead of actually losing weight and getting in better shape so that I could possibly do it for real. Practically speaking, it is less risk and reduced costs to watch the movie than to experience Mount Everest first hand. One has to figure out what they really fear whether it is getting hurt, the prohibitive cost, the inability to select the right equipment without calling up an industry analyst firm, trusting your climbing buddies especially if they are coworkers, etc...