In I.T., are we really spending too much time on "maintenance"?  Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements.

Business Analysis is a term that covers a wide range of different disciplines, which has grown in scope over the past 10-15 years. BAs can become involved in a variety of different activities, depending on the organisation and the particular project that they are working on – these can range from very technical to very business focused activities.  So if you're working as a Business Analyst, or working with a Business Analyst, what can you expect?
 

Contrary to what you might think, the problem that rulebook management addresses is a relatively simple one. Its solution is relatively simple too. The reason people have a hard time seeing that is because the problem is so big. It’s all around us, everywhere we look – a whole host of trees blinding us to the forest.

Regretably, many of today's Systems Analysts are still glorified programmers in sheep's clothing.  I recently came across some job postings under the title, "Systems Analyst," and it occurred to me people still do not know what it means. In the postings I saw things like "seeking a Systems Analyst with 4 - 6 years experience... Candidate must have experience with JAVA and the ATG application framework."

“I may not know much about art, but I know what I like”. This famous punch line to a Monty Python sketch about a fictional conversation between a disgruntled Pope and innovative Michelangelo (who wanted extra disciples, multiple messiahs and a kangaroo in his first draft of the Last Supper), can also be seen to satirize our own modern fixation with creativity, feedback and the idea that ‘the customer is always right’.

Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?

 Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.  Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
 

Like it or not, every business analyst will have to stand up in front of a group and present. The group might be your business clients, the project stakeholders or just your fellow team members but for many people, one of two things will happen: it will frighten the life out of them OR they’ll umm and ah their way through, sending the audience to sleep.  Why is this so?
 

If you work with other business analysts, you are fortunate. Together with your colleagues, you can experience greater effectiveness than you could have achieved on your own.  Additionally, your colleagues can provide you with a diverse and convenient pool of expertise from which to draw.

There is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example. This article discusses various approaches for dealing with business rules and use cases.