How Enterprise Architecture initiatives can survive an economic downturn

As the economic downturn begins to have tangible consequences, IT executives have turned their eyes towards reducing costs within their organizations. Whenever there is an attempt at the executive level to control costs, the primary targets tend to be hardware replacement projects, non-strategic business projects and IT specific discretionary spending. Enterprise Architecture initiatives typically fit neatly into the discretionary spending category, and are one of the primary targets for cutting. I do not believe that cutting EA initiatives serves the enterprise in the short or long term.

The question then becomes how can we best justify Enterprise Architecture initiatives not as discretionary spending, but rather a necessity for future success? To do this we need to position the goals and objectives out of the strategic cloud and deliver tangible results to the organization. This can be done through a series of steps that adheres to the larger charter of the group, while executing tactically.

First, EA initiatives need to be repositioned in the view of the organization as strategically imperative rather that as discretionary “pet” projects. There are a couple of ways that this can take place. One way is to dig in and begin looking at the projects in the pipeline and evaluate the best way to get ahead of the project. We should be able to analyze the patterns that will need to be applied to the Architecture and ensure that the project is in line with the governance framework. Previously, this would have been a challenge, as projects were coming at a fast and furious rate. If cuts are taking place the rate of project approval has likely been slowed, and Enterprise Architects should have an opportunity to get a handle on projects further upstream in the project life cycle. By getting ahead of the curve, the Enterprise Architecture should be able to increase the speed at which projects are delivered and indentify potential trouble spots early on.

A second way is to look internally and identify any pain points that Enterprise Architecture may have caused when it was implemented in the life cycle of the previous projects. Were there any places that the Enterprise Architecture was deemed as a burden to the project teams, and they attempted to work around it in the name of “Getting things done.” By identifying these pain points, we can look to reevaluate where the governance points along the project life cycle became a source of resistance. The various teams that are responsible for the project methodology probably have some breathing room right now and will be willing to sit down and work with the Enterprise Architecture group to solve any issues. This approach will engage the project stakeholders and give them a sense of ownership in the EA initiative, thereby making it less likely that they resist the process once the project pipeline gets ramped up again. This approach will fit nicely in aligning with the strategic vision of tying the business to IT.

Another area that can be examined in the current climate is the application portfolio. Are there any applications not been performing in an optimal manner? Are there any applications that lack transparency or are inherently fragile, causing large amounts of pain when enhancements are implemented? Are there any internal or external interfaces that can be improved dramatically? The common thread between all of these improvements is that they deliver a measurable result and they will solve a problem. The beautiful part about attacking these problems is that applications built outside of the governance framework can be brought in line with established standards.

Now would be a great time to look at different avenues of innovation that were previously dismissed. A good example would be any interface that does address validation or performs some non mission critical task. If the interface was designed in a legacy type technology there could be a cost savings in moving that interface to a SaaS / cloud platform. The hidden costs in maintaining those interfaces most likely far exceed the cost of executing them in the cloud. Identifying those interfaces and experimenting with the replacement technology will not require a great deal of expense, and could act as a stimulus for further innovation.

In addition to the actions that should be taken now, there are a couple of initiatives that should be avoided. Right now is not the time to launch a large scale application portfolio inventory for the creation of a 5 year strategic plan. It is not that it is not valuable to have one, just now is not the right time. The key now is to focus tactically and deliver value. The worst thing the Enterprise Architecture team can do right now is nothing. With the environment slightly depressing, and projects slowing to a trickle, it can be easy to sit back and take a breather. That cannot happen. There is a perception in most organizations that Enterprise Architecture is unnecessary in the first place. By doing nothing, this will be taken as a sign by the naysayers that enterprise had nothing to add when times were good, and cannot help when times are bad.

Key Takeaways:
Look at the project pipeline and identify the projects that are business critical. Work with the business owners to get a head start on the projects that are going to be funded.

Evaluate pain points in the EA governance process as it relates to delivering projects. Work with the business to eliminate those pain points and establish joint ownership.

Take a look at the application portfolio and make someone’s headache go away.

Look at some lower cost versions of existing technology and see if they can cut costs

Do something! Now is not the time to just keep the lights on. It is easiest to be the brightest bulb when all others ones are dark.

Great social networking idea

Despite the fact that my colleagues will probably make fun of me for posting this, but I love the concept. Technobabble 2.0 has created a Vote for the best analyst contest. This is an outstanding use of the social media concept. Because of Technobabbles reach and audience, I think the results should give a pretty good snapshot on how the online community views analysts and could give rise to a new generation of superstars. Along the same lines, I read yesterday that the American Medical Association has been/is working on a standard for creating a doctors rating system. Seems like a pre-emptive strike by the medical field to corral the social network effect that could happen if someone beats them to the punch and deploys a killer doctor rating web app. I know that there currently several of those types of systems that exist, but none of them has reached critical mass yet to have an true impact. It will allow them to set the terms for ratings, establish a standard scoring scale, and possibly prevent disinformation being spread about doctors. I am on the fence for this one. I don't really have a problem with online ratings for lawyers, coders, analysts, companies... ect, but I do have a concern about opening up the medical profession to public scrutiny. Here is the reason why: doctors at higher end medical facilities would be unfairly exposed to more risks online, due to the demographic that they serve. It could skew the results. On the flip side of thing, fantastic surgeons and doctors operating out of "St. Elsewhere" would not be getting the recognition they deserve. If the AMA puts a system in place and all hospitals are forced to give ratings and reviews at the end of every treatment session, we will see a more clear picture on the effectiveness on individual doctors.

Analysts Gone Mad!!!!

Big news in the analyst space this week. It looks like there are some rumblings on Silver Lake Partners selling their holdings in Gartner to IDG. This is not very interesting when you just take a look at the article, but it becomes intriguing when you look are some other news that is swirling around this space. For instance, Gartner's share price has been behaving erratically over the last 6 months, dropping from a high of 28 down to 15, and then immediately spiking back up to 20. All of this movement was generated on no specific news. The second point is that that has been some anecdotal evidence that Gartner has not been very helpful in dealing with existing customer issues & posting new content to the web. They were supposed to have launched a stronger blog/social network initiative, but it looks like it has stalled. Furthermore, Forrester is continuing to push into their space with more effectiveness, and a louder voice. As I am a betting man, I say there is a .20 probability of a buyout of some type taking place in the next year.

Also in the analyst news, hello / goodbye for David Linthicum formerly of the Linthicum Group, formerly of ZapThink, now CEO of Strikeiron. When the Linthicum Group was bought out 6 months ago by ZapThink, I was very excited to see that such a well known industry expert was coming on board to my favorite SOA analysis site. However in reading David's post since the merger, they had begun to take on a far more repetitive / negative connotation. You could actually see the frustration that he was feeling coming through the screen. The short stint at ZapThink bugs me a bit, but only because I had such high expectations of the merger. As expected, both sides are saying the right things about the time spent, but from the outside it just looks like the differing views on SOA were incompatible.

Microsoft Introduces Skyscrapr

Microsoft has launched a new Architect portal called Skyscrapr. It seems to be a convergence portal for all things architecturally related that Microsoft produces. Additionally, I noticed a HUGE uptick in blog postings to the ASDN Architecture Journal over the last couple of days. I didn't check my aggregator for a couple of days, and I had over eighty items waiting for me to read. Here is the RSS Feed:
http://www.microsoft.com/feeds/msdn/en-us/architecture/rss/rssMSDNHomePgArc.xml.

A couple of articles that I noticed that were interesting were:

Pragmatic Architecture : Data Access

The Optimistically Critical Architect

Software Abstraction Layer

The Role of the Software Architect : Caring and Communicating

Yet More Development Angst

As is obvious by my previous post, I'm completely disenchanted with the preachings of the patron saints of technology and their consistent gear switching on "best practice", "best language", "best framework".

Best practice is just that, what works well in practice, not theory. And theory is the domain in which they dwell. I get tired, as much as most of you do I'm sure, of beating the "best practice" drum only to have "best practice" thrown to the wayside for the "just get it done" mentality that EVERY corporation, when put to it, adheres to.

"Best language" and "best frameworks" are both very subjective terms and I realize this. I do, however, expect prophets of a particular "best **/*" to stick to one or maybe two for a few years before they declare the "next" best language or framework.

Just as these same cats a few years ago were mocking client side work and declaring that everything should be done on the server side, they've now switched gears again and declared it should be done on the client with minimal calls to the server. There will be yet another switchback in the next few years as more and more client side code becomes unmaintainable.

All of the switching and technological "discovery" is perfectly fine and good, but if you ask yourself the simple question "Has development gotten easier with the advent of all these new technologies" you'll find the answer is no - emphatically. Not only is it no, it's an order of magnitude more difficult to properly design, implement, and pay for an enterprise level application than it was just 10 years ago...

Users not only expect but demand the same type of functionality and responsiveness that they had 10 years ago when VB desktop apps ruled the world. And here we are, still mired in the same transport level muck we started out in...

Ruby Can Save The World!!!

(This is an excerpt from an email, but I felt that rant wasn't in a public enough forum)...

*** Starting Rant ***

"Why do we continue to re-invent the (broken) wheel?"

The talking heads continue to keep themselves popular on the conference circuit by declaring "new" languages sexy. Where was Martin Fowler when I was playing around with Ruby in the late 90's? Declaring Java the next sexy language.

Do I like Ruby / Groovy / ${insert cool language here} ?

Sure, they're all cool.

I like Lua myself, and have had fun the perl, python, smalltalk, ADA, and a score of other languages in the past. But how about we stop trying to fix the symptoms of our programmatic issues by creating new languages and instead focus on the REAL problems behind them.

Why does web development suck compared to the days of desktop development? First and foremost is the transport, and not far behind is the statelessness. Statelessness has been solved somewhat, but why is it that web development has been going on solid since the 90's and we still have to be concerned with this paradigm of request-response? Why hasn't this communication layer been abstracted away so that development can focus on the important aspects of the project.

JSF and other overly complicated frameworks may help with that issue but introduce plenty of problems of their own. We're absolutely destroying the KISS principle every time we adopt the next flashy framework or language that promises easy set up and next to nothing maintenance - these always have a cost and rarely fix the problem.

How do we fix this? Not with a language or a framework, but a tool. A new browser. One that is actually INTENDED to serve applications and be more than a terminal (and no, Flex, OpenLazlo, etc. won't suffice - those are shoehorn patches). At least that would be a great start and the best first step. Then follow that up with some other improvements to ease data access, configuration, etc...

*** Rant Wind Down ***

Above all I'm beginning to tire of the declarations, musings, and "The Thinker" posings of the Fowler's, Eckel's, and Cockburn's of the world. Look closely (or not so closely) and it's apparent they have their own agendas. They are paid extremely well to pontificate and then talk about their pontifications on the circuit. They are paid just as well the next year on said circuit when they refute what they had spewed just 12 months before...

Not that these guys don't have valuable insight and a vast amount of experience, but they make mistakes - consistently. That's why every other year they are touting the next greatest technology... A good example was the panel of last year's NFJS downright berating Struts - a framework they were in love with only a year or two before.

So my advice is take what they preach, decide on your own if it makes sense, and then either disregard it or tuck it away for use later. Some of the ideas bandied about simply aren't practical (pair-programming being one of them) while others are just goofy (writing a test for a class that doesn't exist just to watch the test (amazingly) fail).


*** End Rant ***

I apologize for this rant but I'm mired in writing documentation and I have reached my boiling point and have had my fill of Magic Cure All Languages (MCAL for short)...

Also, feel free to take my advice above and disregard any and / or all of my musings :)

Maven 2 Remote Repositories - Part II

It appears that archiva doesn't work right out of the box - at least not for it's current version. After downloading and building the project it was still throwing configuration exceptions and wouldn't deploy. So I searched around jira and found a fix for the bug. After following the prescribed steps and creating my own basic archiva.xml in my .m2 directory it worked, at least the test did...

When I continued on to deploying the standalone version to my destination server there was another issue - a NamingException. Turns out someone checked in the plexus.xml config that duplicated a datasource. I just had to go to the conf/plexus.xml file and fix it... I crossed my fingers, closed my eyes, and ran the run.sh script...

It worked!

Now for configuration...

Follow the directions to set up your managed repositories and the repositories that they proxy. Pretty straightforward and works out of the box. The tricky part is setting up your settings.xml

It appears that at this time just setting up mirrors doesn't work unto itself. Mirroring works for any non-plugin repositories. However, for each plugin repository you will need to set up pluginRepository elements in a profile. This is clunky and will hopefully get worked out as the product matures.

The last tidbit that took me a while to figure out is this: Any connection to the managed archiva repository is expected to be secure - meaning it wants a userid and password. This was not abundantly clear in the documentation... You need to set up a server entry in your settings.xml for each mirror / pluginRepository that you you plan on proxying. The userid and password are those that are defined in archiva. I simply defined a maven-user user with no password and assigned to it the role of Repository Observer.

Once you have these set up you are good to go!