Technology for your Mission

These days at NPower I’m known as a Systems Analyst. I’m not really sure what that means (and I picked the title!). Let’s see what the internet has to say…

Princeton word net says it’s “a person skilled at systems analysis.” Well, that’s helpful, let’s try again…

Wikipedia says it’s “dealing with analysis of sets of interacting entities, the systems… and the interactions within those systems.” It also uses the word interdisciplinary a lot.

What this definition seems to say, and what my experience would suggest, is that Systems Analysts deal with just about everything that interacts with and within a system. That means that I figure out what needs to go into and out of the system (sort of requirements gathering), I figure out what the system is going to look like (architecture), and I make sure it gets done (project management). This is not likely to be a description that many agree with, but it fits my job pretty well.

What it doesn’t really capture is the importance of a facilitated, bi-directional, communication of knowledge to make this whole thing work. My job obviously requires that the developer understands what the user needs. But it also requires that the user understand why the developer has to design something in this way. Clearly I have to explain to the client that we can’t finish the project in two weeks, but I also have to explain to the developer that the client has a big due date coming up and needs this part of the system up and running by this date.

My job isn’t to be the wall between the two parties, taking information from one side and reworking it for the other. My job is to facilitate. And boy is it hard!

Today I read a very long — and unnecessarily academically dense — literature review on Pattern Languages in HCI. HCI stands for Human Computer Interaction, and PatternLanguages are sets of linked design patterns (kind of a blueprint for good design). While pattern languages themselves aren’t likely to be very useful for me in my work, the paper did get me thinking about what “language” means within a particular domain.

Princeton WordNet defines language as “a systematic means of communicating by the use of sounds or conventional symbols.” However, this is true only in the most limited sense. A language not only describes meaning, it creates meaning. We cannot truly conceive of ideas outside of language. Language gives us the tools to create new ideas.

The pattern languages mentioned in the paper do something similar. The article uses the word “generative.” That is, pattern languages generate systems by providing a framework on which to design. Designers start at a high level pattern and can follow the web of linked patterns to inform their systems.

So, where does that leave everyone who isn’t an HCI professional?

Only by creating and using a language within a particular domain can we begin to make that domain “real.” Without a framework (language) for thinking, creating, and describing professionals are bumbling around in the dark. Using simple, linguistic, language to describe domain-specific knowledge is certainly important, a first step. Creating specialized words to fill in the gaps can stretch the tool a long way.

However, words aren’t particularly great for more complex, specialized contexts. It’s not like this is a new realization. There are dozens of specialized languages that have arisen from this gap — the most common being any of a dozen diagrammatic languages (UML, IDFX, etc). But its important for us to continue to find new languages to discuss and build on our knowledge.

Free is great. As a member of the nonprofit community, I realize that every dollar not spent on software and support services can be redirected to helping clients. I realize that money is always tight. It’s great that there are innumerable free, open source, and donated tools to help organizations work more efficiently. Google docs, salesforce, google adwords, comparison shopping sites, techsoup, AVG, it’s all there. You can probably find an adequate free solution for just about every issue. So, what’s the problem?

 
You have to find it
This might be the biggest issue. Google, Microsoft, and large companies seem to think that every single nonprofit has someone on staff with technical aptitude and lots of free time. Someone that reads the right blogs. Someone that knows how to search for things.

This is, frankly, not even close to accurate. Non-profits, by and large, are not the young hip organizations that everyone in corporate has romanticized. Many nonprofits are staffed by older, less technically included individuals. Even nonprofits with “young and hip” staff usually don’t have the time to wander around the Internet looking for cool tools.

 
You have to learn to use it
Free isn’t really free. Most of these tools are poorly designed, complicated, or both. That means time — lots of time — installing, configuring, and learning. This is assuming that you can figure it out. Again, many nonprofits just dont’ have the technical aptitude to pull it off. Despite what google seems to think, everyone and their mother can’t learn css, javascript, and mysql in an afternoon.

 
You have to maintain it
Most of these tools — especially the really helpful ones — require periodic monitoring and adjustment. Google adwords campaigns aren’t successful if you don’t update them. Databases need to be updated every time your business processes change or you add a new field for reporting. Ongoing costs, even if they are measured in the man-hours of a salaried individual, can be brutal and unpredictable.

I’m not saying these tools aren’t useful. They absolutely are. But throwing free at the problem usually doesn’t solve anything. Most of these tools should be implemented with the help of a professional and care should be taken to budget for long term maintenance.