I haven't blogged much about technology as it relates to eliminating global poverty, mainly because it's hard for me to do so without talking about the organization for which I work. As has been discussed in the past by Todd Biske, James McGovern and others, corporate bloggers have to be careful to separate our own opinions and stances from those of our organization. Thus, it makes it tricky to talk much about our employers in much detail.

However, I think that putting a gag on myself regarding all issues related to global poverty is a bit extreme. Furthermore, I think that I'm in a reasonable position as an Enterprise Architect working for a non-profit that serves nearly one million children in poverty around the world to try to bring to bear a technology and EA perspective that is shaped by using those tools in that fight against poverty.

I think it's a perspective that is needed, mainly because some people that I encounter in the EA space are surprised to hear that my organization has any kind of IT organization, much less one with an Enterprise Architecture group. I believe a common assumption is that when the main concern is the bottom line and profit, innovative and mature IT is acceptable, if not vital. The unspoken subtext, of course, is that non-profits have no business dealing with (too much) technology strategy and innovation because we do not deal in profit or competitive advantage (I actually think we do deal in competitive advantage, just not in the way you might think... more on that another day). However, a robust and healthy IT organization that is fully aligned to its business is even more important in the non-profit world, simply because the stakes are higher. Not in terms of profits and jobs, but in terms of lives and quality of life. And I honestly don't think that I am dramatizing the issue here, though please chime in if you think I am. I am quite passionate about the subject and might need a cooler head from time to time.

I enjoy the fact that James McGovern increasingly uses his blog to raise our awareness about poverty and to influence others to give to worthy causes. My desire is to add a dimension to my own blog that takes a step beyond "knowing" and "giving" to what we are "doing" with technology in the name of wiping out poverty around the globe. And not just in my organization, either. I think that there are many organizations and individuals out there doing amazing things with technology where the benefit is not a  personal bonus or a shareholder dividend; it is a child who can read and write, a mother who can start a business to feed her family, or a saved life.

Thus, I plan to, from time to time, post articles, links and thoughts under the banner of "Using Technology to Fight Poverty." I might even, on occasion, discuss the work my organization is doing because I am sure that there are those out there interested in where we are going with technology. Furthermore, we know that there are thousands of brilliant people involved in technology that already support our cause and would be interested in knowing what more they can do to help us. However, please keep in mind that anything I discuss around these topics is and always will be solely my opinion and may or may not reflect the opinion of my employer. That actually goes for anything on my blog, but it bears repeating.

 So, keep and eye out for some more posts with this heading. This should be fun...

 I've worked for organizations where IT moves too fast (and thus wastes money and alienates customers) and others where IT moves too slow (and thus the customers go around IT as much as possible). I've also worked in places where IT does both, often in the same day.

This week, I have the pleasure of sitting in all-day meetings related to a series of IT infrastructure projects we are pursuing. The folks in charge of coordinating this effort brought in a vendor to lead a brief engagement designed to help IT project teams and key business stakeholders better understand how to proceed with these key projects. This is a noble goal, and it's one I support. However, I fear that the engagement was put together too quickly and with almost no deliberation. It's just my opinion, of course, and I'm sure that this engagement will have some value. I, for one, want to make sure that we obtain that value even though the process has been a bit hasty. But will it have equal value to the dollar amount on the contract? That I don't know.

To be fair, I'm certain that we're moving quickly in this effort because we've been far too slow with similar efforts in the past. But, it seems as though the pendulum has swung the other direction. So here is the underlying question: How does IT get things done, without moving too fast or too slow? Here are a couple of my thoughts off the top of my head:

1) Empower people in the right places - IT doesn't need to poke it's nose into all areas of the business just because something smells like technology. The question is, what information technologies do we need to be involved in?

2) Respect the Business and Keep them Informed - IT managers like to talk about getting users in the room, then they go and demand they be present without respect for the ever-crushing workload which they have to deal with. If you need to move fast, and you need your customer, it's your responsibility to move mountains for them, not ask that they do so for you. 

3) Remember who you are working for - An extension to number 2. Sometimes is looks like IT is the tail wagging the organizational dog, as if our business units exist to use our technologies. If IT feels the need to get things done fast, then I would imagine that there is a good business reason for doing so (there had better be). If that's the case, its our responsibility to help the business understand how moving fast is our best bet for meeting that need. When we help the business understand that, they get in our corner and help us move as a partner, not someone we feel the need to drag along.

 What else am I missing here? Quite a bit, I'm sure, so additional thoughts would be appreciated.

• Never Email Anyone Over 30 - I've seen many enterprises that think that Email + IM = collaboration needs met and I find it pleasantly surprising to see that IM as a collaboration tool is diminishing in the eyes of the younger generation of workers in favor of things like SMS, Wikis and Blogs (Twitter is probably just about in its own category). What that means however is that the enterprises who are just now getting IM in the Enterprise are still behind the curve... so what's your strategy for embracing the next generation of collaboration tools? Does an Enterprise vendor have to offer it before we'll buy it?
• Practical Enterprise Architecture - Some good tips on creating valuable Enterprise Architecture.
• What is Enterprise 2.0 - As much as I don't like the phrase, or "concept versioning" in any form, I like what the idea represents in terms of driving information access, interconnected applications and devices and collaborative and open work.
• SubSonic - This looks to be a very nice ASP.NET scaffolding framework that parallels much of the project start-up scripts that makes Ruby on Rails such a nice environment to work in. (via Ken Scott)
• Should people adapt to computers? - Agreed Scott. I think that people have adapted enough... it's time to set them free, and I don't mean by turning their coffee table into a computer either.
• Enterprise Architects versus Business Architects - While I certainly don't think that the role of EA is to create services within an Enterprise SOA, I do think that EA has a responsibility in handing valuable business process knowledge to an SOA team that then knows which services are needed. Otherwise, services end up being created to wrap whatever database entities a given project needs next. In any case, the key is that EA has a responsibility to be relevant to SOA efforts, not the other way around.
• Enterprise Architecture is like Herding Cats - Don't know what I could possibly add here...
• Is Serendipity the Heart of the WS-*/REST Debate? Serendipity is probably a large part of the discussion, but I think a key to Nick Gall's General Principle of Serendipity ("Just as generality of knowledge is the key to serendipitous discovery, generality of purpose is the key to serendipitous (re)use.") is that one can rarely (even in an enterprise) plan for explicit reuse of a service. As such, you plan for serendipity.