Jonathan Babcock

Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

On this blog we’ve talked about the imprecision of natural language and the problems it can present in drafting requirements. Forget requirements - what would you think of a tool that could turn natural language into software code? Sounds crazy, doesn’t it? Well, there is already such a tool in the works, although it’ll probably still be a while before they’ve ironed out all the wrinkles.

Writing software has been relatively difficult since people began programming computers in the mid-1900s. Although programming a computer is eminently useful — it gives you fine control of a powerful tool — it requires learning a programming language.

Researchers from the Massachusetts Institute of Technology are aiming to remove this requirement. They have taken a step toward that goal with a language-to-code visualizer dubbed Metafor.

The visualizer uses natural language instructions to sketch the outlines of a program. It can be used as a programming learning tool and to provide rough drafts of programming projects, and could lead to more complete programming-by-natural-language methods.

Formal computer programming languages are difficult to write and inflexible, said Hugo Liu, a researcher at the Massachusetts Institute of Technology. This makes them “quite a pain to debug and maintain,” he said. “Hence the task of programming is rendered inaccessible to the general public.”

Natural languages like English, on the other hand, are universally accessible, said Liu. “Natural language is so semantically rich and flexible that if it could be computationalized as a programming language, maybe everyone could write programs,” he said.

I love the idea. Imagine being able to “code” your own software if you could just articulate what you want in natural language. While the notion seems surprising, I suppose I’ve seen development tools trending this way for a while. I remember being on a project a while back that implemented a rules engine. The notion there was that the business wanted to be able to make changes to promotions and to product portfolios whenever they wanted to, and not to have to wait for a scheduled software release with all of its overhead. This package was to make it so a business owner could make these changes via a relatively simple user interface.

So, while there are obvious implications to software developers here, what do developments like this mean to the business analyst? How will these jobs be affected if/when the day arrives that any old Joe can develop applications? What do we need to do to ensure that our skills aren’t marginalized as new tools simplify what were previously complex tasks requiring specialized training?

I don’t claim to have the answers, but I suppose it is something we should all be considering. What are your thoughts on the tool? On it’s implications? What other revolutionary tools have you heard of that will soon change the way we solve business problems? As always, I’ll be interested in reading your comments.

Ever heard the expression that you should dress for the job you want, and not the one you have? I read this interesting little passage a few weeks back and just thought I’d share.

Today in business, “looking the part” has definitely resurfaced as a priority in the eyes of many decision-makers. Perhaps that’s why so many organizations are encouraging their employees to wear “business ready” attire. Dressing in a “business ready” mode means wearing clothes that ensure that you are one of the first individuals to come to mind when your manager realizes he or she is double-booked and needs an instant replacement for that upcoming meeting. “Business ready” means never having to say you’re sorry for how you look during a meeting. In short, “business ready” attire means dressing for the position you want rather than for the one you have. It’s the best (and most lucrative) approach to business attire, and it’s one you should adopt whatever formal style guidelines your organization promulgates.

Sabath, Ann Marie. Business etiquette : 101 ways to conduct business with charm and savvy -2nd ed. . Franklin Lakes, NJ: Career Press, 2002. Page 42.

Clearly, talent and hard (smart) work are the most important determinants of professional success. By pointing out this quote, I just want to acknowledge that there are also smaller, less subtle details that can weigh in your favor when all else is equal; among them being dress and personal appearance.

What is your company or client’s strategy? Do you know? Has it been formalized?

Some recent articles I’ve read and training that I’ve received has taught me how important a clearly defined business strategy is to meeting organizational goals. What’s more, it’s now plain to me how important the corporate strategy can be in helping to make business and technology decisions. Here’s a quick and (probably overly) simple example I made up to illustrate the point.

Strategy As a Point of Reference

An internet host has built a strong market presence as a low-price, highly reliable provider. In fact, the “quick and dirty” articulation of their strategy was that they would provide the highest rate of server uptime at the lowest price in the market. Their success was based on their ability to do just that.

They arrived at this strategy as a result of competitive analysis of the market that indicated that they had competitive advantages that could be leveraged to differentiate them from their competitors in the areas of price and reliability. As their clientele grew, they began to think of new ways that they could provide value for their customers to solidify and grow their position in the market.

One idea was that they could provide a service to build simple websites for subscribers that wanted it free of charge. By so doing, they could provide more value to their customers, and potentially tap a new market segment; that of customers that want to go “online” but are not computer savvy.

It seemed like a good enough idea, and many decision-makers were initially in favor. As they discussed further, though, they asked themselves how the idea aligned with their strategy as the low-cost, high-reliability provider. Providing a free service would cost the company man-hours, meaning that to maintain their margins they’d likely have to raise prices and risk their position as the low-cost provider. Providing Website services also did nothing to enhance their image of reliability.

Because the new service didn’t support their corporate strategy, they decided not to take it on.

What if they didn’t have a clear corporate strategy? May the decision have been different?

How is this important to the business analyst?

As a business analyst, it is important to know your company (or client’s) strategy so you can ensure that proposed solutions - IT or otherwise - align with where the company wants to be and how it wants to go about getting there. It’s not always enough that “the customer wants it” or to show potential for quick financial returns to justify a business case. While it would be nice to be able to be all things to all people, that just isn’t realistic in most cases. How does the proposed project support company strategy? Does it at all? If not, should we be doing it?

Those are powerful questions and are sometimes difficult to ask, especially of a Sr. Executive about his pet project that, according to him,is going to “solve world hunger.” As a business analyst, one of the ways we can add value is by asking these types of tough questions. An appeal to corporate strategy is an appeal to the overall company vision. While strategy evolves over time, it likely won’t change rapidly over a short period of time because it is usually structured around getting the most out of the company’s core competencies and differentiators.

As a Business Analyst, we may not necessarily be involved in defining strategy, but we do need to be aware of it, and use it as a reference point when helping business stakeholders make important decisions.

Random observations from the February, 2008 Atlanta IIBA chapter meeting.These are not overly important or surprising, I just found them interesting.

• There were between 50-60 attendees.
• At least a quarter of attendees were attending a chapter meeting for the first time.
• It was mentioned that there are approximately 100 members in the Atlanta chapter of the IIBA.

When asked for a show of hands,

• Approximately half of the group indicated that they currently use cases to expresss user and functional requirements.
• Approximately half of the group does UML modelling other than just for use cases (activity & sequence diagrams, etc.).
• Very few - I estimate less than a quarter - use a requirement management tool for traceability.
  Of the group, there were probably 6-8 CBAPS in attendance.

I’ve blogged recently about participating in the business analysis community, and felt like I should get involved in what is going on in my local Atlanta IIBA chapter. Well, I went to the chapter meeting this past Tuesday and thought I’d share a few of my notes and impressions.

First off, it was a good time. I went with a co-worker, and we arrived fairly early. Showing up early gave us an opportunity to meet and visit with chapter president Jonathan Kupersmith (aka “Kupe”) and a few other BA’s. I’m a longtime fan of his company’s business analyst blog, and it was nice to be able to discuss the business analysis and blogging for a few minutes with Kupe. After food (quite a bit, actually) we heard an interesting presentation by Keith Barrett of the Sky IT Group.

He presented a formula for accelerating the requirements lifecycle. The gist of the presentation was that for the past several years, companies have been focusing their resources on tools to aid in requirements management, with the promise that tools would improve requirement quality. In fact, while those tools have matured and become very good at what they’re designed to do - manage requirements - they have not done a great deal to improve requirement quality.

He anticipates that the next frontier in improving the requirements lifecyle will be to improve quality of articulating and and communicating requirements, and that to do so, focus will be turned to ways of visualizing and simulating requirements. All in all, it was an interesting presentation.

As it turns out, I understand that a related presentation will be made available via the web in what I presume will be sort of a “webinar” format. Thanks to Requirements.net for the info.

All in all, the meeting was a very positive experience and I’ll look forward to attending future meetings and events.

Speaking of Requirements.net, it was at the meeting that I initially heard of the website, so I rushed to check it out. In their own words,

Requirements.net is home of the industry consortium for business analysis. Through focus on requirements definition, visualization, and management, the companies behind Requirements.net are driven to share and sponsor best practices and technologies to improve industry requirements practices.

“Consortium” members appear to be HP Software, Blueprint, RQNG, Orasi, Sky IT, and CorTechs. Between the blog, the whitepapers, podcasts, presentations, etc., it looks like there will be something there for everyone. It will be interesting to see what types of problems they’ll tackle, and how they’ll go about doing it. In any case, go check them out. It looks like requirements.net may become another nice resource for business analysts.

I just RSVP’d to attend this coming Tuesday’s Atlanta IIBA chapter meeting. This will be my first time attending, and I’m really looking forward to it.

I know of one or two readers in the chapter that have happened by this blog, so for you and any others who may have happened by, I look forward to meeting with you on Tuesday.

For those of you in the area, here are the details as I know them:

When:
Tuesday, February 26, 6:30 PM

Where:
UPS
55 Glenlake Parkway NE, Atlanta
Sandy Springs, GA 30328

RSVP by February 22, 2007– events@atlanta.theiiba.org
Cost to attend – Free for Greater Atlanta Chapter members, $5 for non-members

Topic: “Redefining the Requirements Equation: RLA = T3.”
Speaker: Keith Barrett, Business Development Manager, Sky I.T. Group

I get my information on IIBA happenings in Atlanta from the chapter website, and the IIBA Atlanta Yahoo Group.

Actually, the true 1 year anniversary was on the 9th, but I thought I’d do as I do for most other birthdays, and forget it completely until a week or so has passed. So, we’ve been at it for a little over a year, and I think it is an appropriate time to thank all of you who have stopped by to read and comment on my posts. Thanks for subscribing to my feed and occasionally bookmarking my posts. I’d probably blog just for my own benefit anyway, but it sure is more enjoyable when you get to exchange ideas with other respected and accomplished practitioners of the trade, and benefit from their experience and expertise.

I have more to say, but first here are a few fun facts about jonathanbabcock.com’s first year (thanks to the productologist for the idea).

Number of visitors: Approximately 12,300 unique visitors. I can’t give the exact number because 3 tracking mechanisms each return slightly different results. Ok, I’m not breaking any records, but it’s more than I would have guessed a year ago.

Number of Posts: 67 (an average of just over 1 per week)

Number of Subscribers: Typically between 100 and 120 on a given day.

First commenter: Michael Schaffner. By the way, Mike’s “Why I Blog” post that he wrote about a week after I began my blog helped me understand the value of establishing a personal brand and inspired me to get off my tail and start taking blogging seriously.

My Favorite Posts:

• McDonald’s Burgers and High-Quality Business Analysts
• Good Requirements Are More Than Just Accurate
• Thought, Problems, and Business Analysts
• Business Analysts and the Abilene Paradox
• Business Analysts: SME’s or Generalists?

Number of different blog themes used: 4. In case you’re interested, here’s the list:

• Blue Zinfandel by Brian Gardner
• Blogging Pro
• Zeke by Solostream
• Suhweet also by Solostream. This is my current theme, btw.

One of the reasons I wanted to begin blogging was so I could learn more about “why” we do the things the way we do as business analysts. I wanted to learn more about how other people in other types of environments deal with challenges common to all business analysts.

I spend each working day in the trenches applying process, methodology, my own professional skills, etc., to make projects work. Over time, I have improved quite a bit at the daily, tactical business analysis activities. What I found that I didn’t have as a daily practitioner was an effective outlet to help me broaden my knowledge of the general concepts, approaches and skills that would make me as well-rounded a BA as possible. I think the blog has definitely helped in that area. Instead of an extension of work, this has really become an enjoyable hobby.

Another benefit I’ve found is that actually composing my thoughts in printed form has helped me evaluate them more fully, and challenge them in ways I hadn’t before. Sharing my thoughts on the Web has pushed me to do some additional research into some of the things I’d always believed and to challenge previous assumptions to make sure that they would withstand the scrutiny of an informed and intelligent base of readers (you guys!).

Anyway… the blog has been great for me. I hope it has been of some use to you, and will continue to get better with age. Again, thanks!