BA: Am I Certifiable?

Thursday, August 5, 2010 by Aaron Whittenberger
Like Adriana Beal, I am often asked by BAs and aspiring BAs if I think that becoming certified would be a good career move.  Adriana covered the Certified Business Analysis ProfessionalTM (CBAP®) certification from the International Institute of Business Analysis (IIBA®) very well.  She noted two situations in which she, and I, would recommend you to obtain the CBAP® certification:
  • the job titles on your work history do not reflect your experience in business analysis (they include other titles such as programmer, software developer, financial analyst, etc.) and/or;
  • you spent many years doing business analysis work for one company (perhaps even with the title of BA), but never obtained post secondary education, and is finding it difficult to get your resume noticed by other companies.
So I will cover the new Certification of Competency in Business AnalysisTM (CCBATM), just introduced by the IIBA.  This certification is targeted to the intermediate BA who has not yet achieved the 5 years of BA work experience required by the CBAP®.  The IIBA has positioned this certification as a stepping stone to the CBAP®, as such it does not have a recertification process.  The CCBATM is good for 5 years and it is expected that within that time most recipients will achieve their CBAP® certification.  If not, you will have to sit for the CCBATM exam again.

So is it a good idea to get the CCBATM certification?  There are many good reasons to obtain a certification; Adriana points many of them out in her article so I will not repeat them here.  However, I am often asked this question by BAs with no or less than one year of work experience.  They clearly do not meet the requirements of the CCBATM certification; so what is the alternative for them?

The alternative to a certification for someone who is just starting out their BA career is a “certificate” from an education provider that you have completed some training in a specific area.  It is advisable to get your training from an Endorsed Education Provider (EEPTM) of the IIBA so that you know that what is being taught is in line with the IIBA Business Analysis Body of Knowledge® (BABOK®).  One other recommendation for those just starting out their BA career, go ahead and join the IIBA now.  Just putting your IIBA membership on your resume shows your dedication and passion for the BA profession.  It also gives you an excellent talking point during interviews.

As you are beginning your career as a BA, concentrate on improving your BA skills and gaining experience in a breadth of BA tasks and techniques.  Remember, work experience can stand alone on your resume; a certification (or certificate) can not.

Why? Because that’s The Way It Is!

Friday, July 30, 2010 by Matt Warman

If you thought your job as an application development person is difficult, try being a consultant. I love my job as a consultant because I am able to affect change, that is, when people want it. The most dreaded phrase a consultant can hear is “that’s the way it is”. Those words have no rebuttal, no further review. It’s the organization’s way of saying “talk to the hand”! My job is to find gaps in code or process and bring them up to the client. Often times the client has fallen into way of doing things that are counter productive, or more likely, have not changed since the process was in place. A case in point, I was having a discussion with an architect about code review. I noticed that they had the Legacy style user, date, and change comments at the top of their classes. I made a review comment that they weren’t necessary, because Subversion tracks the changes for them. It was due to their work process that comments would be lost by Subversion on multiple merges. I mentioned that several high profile companies use Subversion and don’t seem to have a problem. The architect said that research was performed and it doesn’t, and if I have a better solution, I should do my own research before making a comment. I told him that software does indeed improve, and that if research has been done, it should be reviewed periodically to see if the issue had been fixed. I did research the issue, and Subversion did have bug but was fixed, and my client could use comments in their merged code. The key here is that the staff complains that changes don’t get done, but when they are in a position to make it better, they don’t do it. If anyone investigates a new technology or work process it should be DOCUMENTED AND REVIEWED! I don’t know if it will be investigated because it seems like a trivial issue, but the main problem is that the application development people complain that nothing changes. It’s our Culture. Culture is people, and all people, especially application development people can change culture. If there are deprecated methods and TODOs in production code, bring them up in your code review. I don’t accept “that’s the way it is” as a reason. You can’t change a decision for business reasons easily, but you can fix how things get done. If I don’t like the way that it is, I make it better.

Seven Deadly Sins of Consulting, Part 2.

Monday, July 26, 2010 by Jeff Welsh

See Part One here.  These deadly sins are not limited to IT Consulting in Cincinnati, but everywhere.  I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.


5. Blame it on Rio.  And I am not talking about the movie, I am talking about pushing the mistake/error onto something else like, the Operating System, another consultant or worse, one of the client’s employees.  While the problem could very well be any of those things, your job as a professional consultant is to find solutions and to set an example in leadership and even diplomacy.  While you may see glaring errors or mistakes and perhaps your way would have been the better way to do something it is best to keep the criticism and commentary to yourself. (See #3 in Part One)

6. Bubble gum and baling wire.  Many times consultants are brought in to fix something.  The last thing you want to do is to take a shortcut that you aren't sure will last. Band-Aids are fine if you know you are coming back to make a more permanent fix. But eventually, those shortcuts will fail and will need further attention and the time to failure is an unknown. It could be the minute you drive away or months later. This is not the type of chance you want to take. It frustrates the client, and it makes you look bad.  You also don’t want to make the client totally dependent on you.  A client told me once that Peter (not the real name) is very talented; the problem is he is the only one that knows how it works and can manage it.

7. Showing up, Gotta Go. (AKA I gotta hangnail).  Once you’re on a gig, most clients want to see you on some sort of regular basis and some might have a “core hours” expectation.  It’s important for both the client and the consultant to know what each should expect.  I once heard a client make a comment about another consultant that went something like this: “Larry(not the real name) runs out of here all the time and uses sickleave for a hang nail!” 

Here is another list that has some similar ideas here.  I’m sure there are others.  So go forth and sin no more!
 

Seven Deadly Sins of Consulting, Part 1.

Friday, July 23, 2010 by Jeff Welsh

You have probably heard your parents or grand-parents talk about when they were younger and how they had to walk to school, up hill both ways.  When they shared this story with you it was to prepare you for times when things weren’t so easy and to provide you with their knowledge and advice from their hard earned experience. I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

1. Bill for time not worked.  This will be the quickest way to end up out of a consulting gig. Make sure you bill the client only for the time you actually work. This can be tricky if your clients are friends. When you go to a job like this, you know there will be a period of time spent socializing, especially when you first arrive. Don't bill for this time. Start the billing period when you start working.  Sometimes clients will have celebrations during the day.  If you don’t want to appear anti-social, by not going, just don’t bill.  If there are any questions, ask the account manager to find out. If you are the account manager, ask your client manager at one of your one to one meetings if it’s ok to bill.  Some client’s have a culture where that is part of the expectation.

2. Negotiate rates and make deals with the client.  If you work for a consulting firm, you know there are channels for clients to go though to make requests..  Most firms have some sort of account manager to handle those issues.  Direct the client to the account manager.  I had one consultant that actually went so far as to look in the client’s AP system to see how much we were getting paid and then wanted to negotiate a higher rate with the client.  This particular action did not end well for the consultant and he has not been able to be considered for other assignments in this client even when his skill set was ideal.  Never, ever work out a side deal or moonlight with a client this can comprise your integrity and jeopardize the trust between  you, the consulting company and inevitably the client.

3. Act like a prima donna.  Yes, you’re good, that’s why you have been hired. I actually heard a consultant tell the client that their employees were stupid.  Hello? You are there to serve those employees.  You don’t know what kind of constraints they have had to work with.  Hind sight is always 20-20.  Its always far better to politely make suggestions. You may find out your brilliant idea was considered previously and there was a very valid reason for it not being implemented.  It’s much better to NOT have egg on your face or your foot in your mouth.

4. Miscommunicate or undercommunicate when engaged at a client I believe that the client should know what is going on with their project.  Many times I have had to be the bearer of bad news.  I also like weekly status reports to let the client know what I have worked on and what I’m planning on doing.  If at all possible I like to let them know a percent complete.  Years ago, I heard another consultant tell the client he was “unit testing”.  The client assumed that meant he had all the functionality done and was testing.  The reality was he had about 10% of the functionality done and was testing just that one small piece.  When the truth came out, it was not pretty.

Tomorrow I will finish off the last 3 sins.
To be continued……

Business Case vs. Project Charter; Do You Need Both?

Monday, July 12, 2010 by Aaron Whittenberger
A few months ago I wrote on the benefits of developing a Business Case and how it should be used during the IT Governance and SDLC (Waterfall) process.  My main point was that the Business Case document needs to be revisited at different points in the SDLC by the IT Governance body to continue to give its blessing to the project.  At any point, yes even after development, the IT Governance body can hold up the “halt” sign on the project when factors or the environment has changed to make the project solution of little to no value.  However, this can not be done when the IT Governance body reviews the project and the Business Case only at project inception.  Constant review of the business case also assists in initiating the risk mitigation plan when factors or the environment changes that makes such mitigation necessary.

Today I look at the Business Case from a different perspective, that of Project Management.  I have been involved in organizations that did the Enterprise Analysis activities that identified a business need and built the business case for a solution.  The business case was brought before, and received the blessing, of the IT Governance body and a new project was born.  It was then turned over to a Project Services team whose first task was to create a Project Charter.

I found it amazing that the similarities, in format and content, between the Business Case document and the Project Charter document were far greater than the differences.  Some sections were reordered and some content was moved from one section to another, but essentially it would be easy to swap the names on the documents and most people wouldn’t even notice.  Other than the intended purpose and audiences of the documents, they were essentially the same document.  This naturally leads to the question: Do You Need Both Documents, or is it a great waste of time?

Yes, the Project Charter defined a few details in greater detail than the Business Case, but also realize it was written at least a week later, when more factors were known.  Also, such content as risks and mitigation plans were then transposed, and further defined, into the project’s design documents.  So why can’t the Business Case be used as the Project Charter?

In most cases, I would submit that the Business Case should be used as the Project Charter.  Remember the Business Case has received the blessings of the IT Governance body and should therefore direct the scope of the project.  Going back to the IT Governance body for approval of a Project Charter mostly restating the contents of an already approved Business Case would definitely be overkill and put undo burden upon the IT Governance body.

One case where Project Charter(s) are necessary after the approval of a Business Case, is when that Business Case is to be split into multiple projects to bring about the Business Case solution.  In this scenario you would want a Project Charter for each project to define what part of the Business Case scope that particular project was initiated to handle. 

In rare, very complex, business problems with complex business solutions you may find need for both a Business Case document and Project Charter document(s).  In most cases, even in large companies, using the Business Case to define the scope and reach of a project is sufficient to get the job done.

The Value of Communication

Monday, July 12, 2010 by Matt Warman

There are many skills needed as an application development person to be successful, but none more important than communication. In fact, that is point of our job, to be able to communicate to our peers, partners, and customers. I believe that most organizations make money in spite of the immense lack of communication. Most of the application development people I know complain more about the policies and procedures than about anything else (although it’s always something!). Aren’t policies and procedures communication? Certainly, but it’s the internal communication that enables and drives the external communication. Everything we do has an impact on our ability to communicate. Say the wrong thing to a journalist, and you will be removed. Miss that deadline, forget about the promotion. Governance is important for the security of communication, but when do these rules get reviewed? Ask any software development person or manager why, and the answer usually is “that’s how we do things here”. The real answer is that someone set that restriction to an event that happened long ago, and nobody is willing to change things. If communication is the life blood of an organization, why would we restrict the life blood arbitrarily?  If this sounds like your organization, maybe you need to review how you are handling your communications. If you need help, STAR BASE Consulting has years of experience triaging your life blood, and making it flow easier, better, and stronger.

BA: Building Maturity one Building Block at a time!

Monday, June 28, 2010 by Aaron Whittenberger
What an exciting time to be a Business Analyst!  Why do I say that?  Because there is so much going on within and for the profession; within organizations worldwide as well as for the profession globally.

Those that follow the discussion forums on the Business Analysis groups (BA Forum, IIBA®, Modern Analyst) on LinkedIn, have seen me post and comment.  I have seen conversations develop into two opposite points of view, usually between two individuals, and neither side is willing to change their view, nor consider the other view.  When conversation degrade to name calling, you just know that if these two individuals were in the same room that they would be putting on the boxing gloves and it would be a knock-down, drag-out fight to the end.   What I think these people are missing…or seem to forget…is history.

Whether you wish to admit it or not, the profession of Business Analysis is still very much in its infancy.  It is growing dramatically all over the world.  Look at the IIBA membership and chapter start-ups over the past few months.  This leaves very widely spread opinions as to what the job of a Business Analyst is.  Business Analysis or the IIBA does not enjoy the history and recognition that Project Management and the PMI® receive today.  Someday it will, and the IIBA is growing maturity one building block at a time.  Let’s take a look.

The PMI was incorporated in 1969, offers 5 certifications, has over 300,000 certified individuals and the PMBOK® is in its Fourth Edition.  The IIBA was incorporated in 2006, offers one certification and is adding its second by end of the year, has less than 1,000 certified individuals and the BABOK® is in its Second Edition.  Even ITIL® can be traced back to the British Government of the 1980’s.  Six Sigma also got its beginnings in the 1980’s.  So the IIBA and the Business Analysis profession does not get the recognition that these other professions, methodologies and/or approaches get at the C-level within organizations.  It took some time for organizations to recognize these others, they want to see quantifiable results.  Business Analysis is getting there; they are proving their value to organizations every day; and with time it too will get its due recognition.

So what is the International Institute of Business Analysis® (IIBA®) doing to help the cause?  A few months ago they launch the Online Library, last month they release the second version of the BA Competency Model, and recently have announced their second certification level.  Promised in coming months is the Agile extension to the BABOK.  Make no mistake about it, the IIBA stands behind and for the Business Analysis profession.  They are building maturity one building block at a time.  As with all previous professions, methodologies and/or approaches organizations will be slow, but will eventually, adapt and recognize the value.  BA Center of Competency and Center of Excellence are beginning to get recognized for the value they bring to the organization.

So why is it an exciting time to be a BA?   Because we current practitioners are in on the ground floor.  How often do you get an opportunity to define a profession for the world? Just as the framers of the PMI and PMBOK did 40 years ago, we forge a new area for the world to follow.  Wouldn’t you grab the bull by the horns?

Don't Repeat Yourself (DRY)

Monday, June 21, 2010 by Mark Murphy
I have been programming/consulting for over 20 years now, mostly in Cincinnati, and it still astounds me how many coders do not update thier style as trends change.  I have heard that if you want to see how things were ten years ago, then go to Cincinnati, but that is beside the point.  I have recently been working on an application that was admittedly written some time ago, but in an environment that encourages sharing of code, fields, forms, etc.  It seems that the developer only dabbled with code reuse.  In form after form, agent after agent, I find the same code, or code that attempts to do the same things, and frequently in a brute force manner.  Needless to say, maintenance of this application is a nightmare.  Highly frustrating.

Coders - DO NOT REPEAT YOURSELVES.  Put your code in reusable general purpose functions, and then reuse them.  Refactor your work if you need to add a parameter.  If you find yourself writing a bit of code (e.g. getting a configuration value) more than once, put that code in a function, and call it next time rather than writing the code again.  The goal is not to reduce the amount of code you write, though sometimes that is a result of DRY coding.  The goal is to improve the maintainability of the code.  If at some point down the road you need to change the way you retrieve a configuration variable, you don't have to go change the code in a million places, you simply change it in the one function whose job it is to retrieve the value.

Business Analyst: The Most Important IT Role

Friday, June 11, 2010 by Aaron Whittenberger
Now didn’t I say that Business Analysis has far reaching impact on the organization?  A new Forrester research report supports my claim as it ranks Business Analyst #1 of the 13 Most Important IT Roles.

The age of IT specialization has been replaced by an emphasis on skills that can translate across the enterprise. According to Forrester, this shift can be traced to a number of emerging trends:

* Maturing technologies such as software-as-a-service and business intelligence are changing IT skills requirements;

* The growing array of outsourcing options have altered in-house staffing priorities, with more specialized skills increasingly likely to be outsourced; and

* The continued search for cost-reduction opportunities has changed how IT decisions are made.

With those trends in mind, here is Forrester’s list of the 13 Most Important IT Roles, based on the percentage of IT executives who believe each role is growing in importance.

#1 – Business Analyst – 70%

Talk about holding all the cards: Not only do these IT pros know the business, they also have their fingers on all the insight.  As the saying goes, knowledge is power.

#2 and #3 – Architecture and IT Strategy/Planning – 66%

As IT has evolved into an increasingly important part of business, both of these roles have become critical in ensuring that every department has the infrastructure and tools that it needs.

#4 – Project Management – 65%

What business doesn’t need people who can mange multiple personalities, master numerous business processes, understand different aspects of the business and make sure things get done?

#5 – Security – 62%

With the onslaught of breaches and identity theft that constantly filters through the headlines, not to mention the growing mandates for better access controls, is there really an explanation needed here?

#6 – Service Management – 60%

The whole thing about the customer applies here to, as managing IT from the customer’s perspective has become de rigueur.

#7 – Client Relationship Management – 56%

We’re in the age of customer service, and anyone who’s mastered the art of managing CRM environments is worth their weight in gold.

#8 and #9 – Business Continuity and IT Financial Management – 55%

With companies paranoid about their systems surviving natural and man-made disasters, and cost-effective IT spending more important that ever, it’s no wonder these roles are on the rise.

#10 – Portfolio Management – 50%

This is a growing area driven by the desire to demystify the measurement of the impact of IT investments.

#11 – Asset Management – 34%

Like other spin-offs from more general business roles, this is another specialized function better outsourced.

#12 – IT Research – 30%

Research? That’s what consultants are for.

#13 – Human Resources (within IT) – 20%

HR for IT is an increasingly unnecessary luxury in an increasingly self-service environment.

Take a closer look at that list and you will notice Business Analysis has been ranked #1, #2, #3 and #10.

Business Analysis has far reaching impact on the Organization

Friday, June 4, 2010 by Aaron Whittenberger
Keith Ellis compares the business analysis profession to an iceberg in his article on BA Times.  He notes that it looks small on the surface but when you get into it how much of “the job” is not visible on the surface.

However, my take away from this article is about the impact of business analysts on the organization. “..not in little ways. In a big way!”  Business analysis done properly can impact the organization unlike any other role within the organization.  It literally changes the way the organization does business.  It impacts every business unit within the organization and can affect project portfolio, financial performance, product offerings and speed to the market; all affecting competitive advantage. 

You must also realize the negative impact that BAs can have on the organization when business analysis activities are not performed correctly, or not at all.  It can also have a negative impact on competitive advantage.  As Keith says “This is not an IT thing, it’s a business success thing.” 

We practitioners often get bogged down in the day-to-day activities of the job and loose site of the impact we have, or can have, on the organization.  Sometimes it is necessary to stop, take a deep breath and re-visit our own impact on the organization.  Implementing a BA Center of Excellence for the organization can go a long way in ensuring the business analysts’ impact on the organization is positive.

What is the BA impact in your organization?

Know Your Role

Thursday, May 20, 2010 by Matt Warman

I am finding out things at my current client that everyone, including application development people knows; having a process is only half the battle. I have been to organizations where business workflow processes were not in place, and the productivity gains were huge when implemented. But over time, those processes stop getting followed. There are many reasons for this; the IT culture rejects the change, the processes don’t get reviewed in a timely basis and become a burden, and the players forget their role.
My client has a decent development workflow in place. Analyst get requirements from the business units, architects turn the business requirements into technical requirements, and application development people execute the requirements. Managers should manage the process, making sure that the resources are available when needed. I always wondered why top technical guys get passed over for management in favor of PHB (Pointy Haired Bosses), and now I know. It’s that PHBs know their role. Managers are managing the PROCESS, not the solution. Often, technically savvy managers want to work the issue. Software development is a very fluid process, and what works now, may not work three years from now. If you are manager for more than six months, you probably don’t know the correct solution. Regardless, your role is to make sure application development staff are available for the solution designed by the architects. Managers have a right to review the design during the design phase, but once finalized, let the architects and application development people do their jobs.
The same is true for consultants. Yes, they are using older technology, and yes it’s a pain to use, and yes it needs to be updated. Your job is to help resolve those issues within the framework of their organization. Unless you are brought in as a CIO consultant, the choice is probably not yours to make. It may be that the business has urgent needs that supersede modernization. They may not have the technical people to maintain the new code. The organization could be planning to replace the system with a prepackaged application like SAP. Or it could be that the technical staff knows their role, and is waiting patiently for their opportunity to upgrade.

IT Governance Needs to Change to Gain a Competitive Advantage

Friday, May 7, 2010 by Aaron Whittenberger
Futurists have been fore-telling the look of the business enterprise and the IT Department for years.  The latest version from the Corporate Executive Board state that we are in for rapid, radical change.  It fore-tells that the IT Department in 5 years will bear little resemblance to the IT Department of today.  As business users become more tech savvy, the business units will absorb a lot of today’s IT functions.  Along with continued IT outsourcing, they predict that only 25% of today's IT professionals will still be in IT in 5 years.

The CTO blog does not forecast such a dismal future for the IT professional, but it also acknowledges the need for better alignment with business strategic goals and faster IT solutions delivery.

Whereas, I will not completely buy in to the idea that 75% of today’s IT professionals will not be working in IT in 5 years or that change will be so rapid or radical.  It is increasingly apparent that change in IT solution delivery is necessary, and that is where I suggest that business organizations start; in particular IT Governance. 

I hope to see today’s IT Governance Committee, which approve and prioritize IT business solutions projects, replaced with a Business Improvement Project Review Board who approve and prioritize all business improvement projects.  This new Governance Body will consider all business improvement projects; those with business solutions and those with IT solutions.  As I mentioned a few weeks ago this new board needs to better track all projects and continue to give its support to all projects at every stage of the project.  Once the cost of the project outweigh the benefits, or other external forces make continuance of the project unwise, the project can be stopped and decrease the expense to the organization.

Along with that we will see the idea of a Project Management Office (PMO) replaced with a Business Improvement Office (BIO).  The BIO will be staffed with people with business backgrounds and those with IT backgrounds; however, cross-training and best practices will require all members of the BIO to look for the best solution, considering both business and IT solutions, to meet the needs of the business.  The BIO will take over the project management, business analysis and quality assurance aspects of a project. 

Continued competitive pressures will force the BIO to change its practices in order to achieve faster solution delivery.  Some will embrace the Agile methodology; others will develop some hybrid methodology taking parts from both the Agile and Waterfall methodologies.  However they achieve it, continued pressures for competitive advantage will require continual improvement in the methodology to push for faster and faster delivery while not sacrificing quality.

Many references now forecast a change to IT Departments and IT staffing as we know it today.  It will be interesting to see the changes as they come about and see which forecast was most correct.

Making the Business Case for an Internal BABOK

Friday, April 30, 2010 by Aaron Whittenberger

As I move from client to client, IT shop to IT shop, the one think I notice is that most organizations do not have an internal BA Body of Knowledge.  There are several reasons that I can think of as to why organizations have not taken on the task of developing an internal BABOK:

    1. Companies are slow to embrace the idea and value of a BA Center of Excellence.
    2. Companies do not understand what an internal BABOK is and what should be in it.
    3. Companies have not realized the value of an internal BABOK.
    4. Not enough time, not enough resources.

So let’s take a look at these reasons.  First, creating a BA Center of Excellence would allow the organization to use their BA talent in a more strategic role within the organization.  It would allow them to move their BAs among the business units within the organization with a much less learning curve.  BAs leaving the organization don’t take valuable business knowledge out the door with them and just as important, new BAs have a much shorter ramp up time to become effective to the organization.  I believe once organizations realize the value that developing a BA Center of Excellence can have on the organization, they would all want one.

Secondly, there is reference material available that conceptually describes an internal BA Body of Knowledge, but you would have to dive deep into reading material to find it.  So, let me spell out for all to see what we are talking about when we say an organization should develop an internal BA Body of Knowledge.  This is a centralized, electronic copy of documents that define anything within the business.  This is a wealth of knowledge that all your BAs can draw from to better perform their duties.  This would allow a BA to learn a new area of the business quickly that they have not worked in before as they are assigned new tasks.  This BABOK would define the business organization, the business units with it and the interrelationships between those business units.  What did that sound like to you?  If you said an Enterprise Architecture, you are absolutely correct.  The first thing to include in your internal BABOK is the organization Enterprise Architecture, including all five parts of the architecture.  Also include the BA Career Ladder, BA Competence Model, BA Job Descriptions, new BA training material, BA departure review and BA reference material pertinent to the organization.

Thirdly, now that you understand what wealth of knowledge is included in an internal BABOK, I think you can realize the value of it without me saying a word.  Most organizations do not have an Enterprise Architecture, let alone an internal BABOK.  Those organizations that somewhat have one; usually have it dispersed all over the company network, which makes finding material very difficult.  Centralized, easy to access, electronic, included in the company’s backup and restore process adds tremendous value to the organization.

Lastly, this is always the reason that many good ideas do not take form.  Realize, that if you had an internal BABOK that your BAs used on a daily basis that research tasks take a lot less time.  This can decrease project schedules, freeing up more than just BA resource time.

That all sounds nice, but what does it mean to the organization?  Well, there are many benefits to having an Enterprise Architecture and internal electronic BABOK to the organization:

  1. Project portfolio in greater alignment with business strategic goals and initiatives
  2. Realization of BA talent in a more strategic role
  3. New BAs become more effective to the organization faster
  4. Ensure enterprise knowledge stays within the organization when BAs leave the organization
  5. Starting point for Enterprise Capability Gap Analysis
  6. Reference material for new product feasibility studies
  7. Reference material for competitive edge analysis
  8. Required material for new enterprise software impact analysis

There are many benefits to the BA practice within the organization:

  1. Reference material easily available without exhaustive searching
  2. Understand BA Competencies important to the organization
  3. Understand BA Competencies needed to achieve the next level on the BA Career Ladder
  4. Move within the business units of the organization with greater ease and knowledge
  5. Needed reference material for Enterprise Analysis activities

Now can your organization survive in these economic times without an internal BABOK?

 

IT Skills in Demand for 2010

Wednesday, April 7, 2010 by Aaron Whittenberger
The Job Search website Dice.com recently released the top 20 IT Skills in demand in Today’s Market.  They also show the percentage increase in demand for that skill over March of 2009.  The list consists of:

1.  Informatica (database) 71%
2.  Virtualization 70%
3.  ETL (Extract, Transform and Load) 57%
4.  Python (web programming) 57%
5.  Service-Oriented Architecture (SOA) 55%
6.  Sybase (database) 52%
7.  WebLogic (application server) 50%
8.  SOAP (web programming) 48%
9.  Data Warehouse 47%
10.  SharePoint 41%
11.  MySQL (database) 40%
12.  E-commerce 39%
13.  JavaScript (web programming) 36%
14.  VMWare (virtualization) 36%
15.  CSS (web design) 36%
16.  Business Analysis 35%
17.  ITIL 34%
18.  Ajax 34%
19.  Perl (web programming) 33%
20.  Business Intelligence 33%

As you can see from the list Database, Virtualization and Web programming are still IT staffing skills very much in demand, as they have been these past few years.  The one IT staffing skill that I noticed that no longer makes the list is IT Infrastructure (Network Administrators, Network Engineer).

Homeshoring, the new trend in IT Outsourcing!

Tuesday, March 16, 2010 by Aaron Whittenberger
According to an InfoWorld article this month, the U.S. IT market has added 25,000 jobs in the first two months of 2010.  This is the largest month-to-month gain in IT staffing jobs in the U.S. since 2008 according to U.S. Labor Department statistics.

A contributing factor to that increase may be a new trend in the IT Outsourcing called “Homeshoring” or “Onshoring”.  This is an alternative to offshoring your IT outsourcing by placing it in low-cost, non-urban U.S. areas.  Monty Hamilton, CEO of Rural Sourcing Inc., recently spoke at the 2010 Outsourcing World Summit, where the idea of homeshoring was well received.

As salaries in India increase because of past American offshoring IT strategies, rural America becomes more competitive.  This along with the other benefits, such as culture and the favorable time zone, may spark an increase in the coming years to homeshoring. 

Mr. Hamilton notes that Small to Mid-sized Businesses (SMB) are first to realize the benefits of homeshoring.  He also makes note that a few jobs may still be lower cost as offshore, such as moving stack A to stack B.  However, when it comes to IT staffing, enterprise application development and IT strategy consulting, homeshoring is the growing trend.

What makes a good BA?

Friday, February 26, 2010 by Aaron Whittenberger
I have spent a lot of time talking about the duties of the Business Analyst (BA); now let’s talk about the characteristics that make up a good BA.  I find it interesting that Kupe wrote on this very subject this week, I guess great minds do think alike.  As Kupe notes, the IIBA call these underlying competencies and define these as “the skills, knowledge and personal characteristics that support the effective performance of business analysis”.

The BA performs an important role in the application development process and is tasked with the duty of ensuring that the IT business solution meets the needs of the business.  The BA develops and maintains the business and functional requirements that the IT business solution must contain in order to be deemed successful.

So we know the role and duties of the BA during a business application development project, so what “skills, knowledge and personal characteristics” does a person need to have to perform these duties.  As the duties of the BA entail eliciting requirements from stakeholders and working with an application development team, you can imagine that communication is at the heart of the competencies of a BA.  Good written and oral communication is necessary in order to be able to perform these duties.  Good communication is not only departing information, but taking in information, or listening.  This is often the skill that is over looked when we talk about skills or create a competency model.

Notice that when discussing competencies, that we not only are talking about “skills”, like Decision Making, Creative Thinking, Learning and Problem Solving; but we are also considering “knowledge” and “personal characteristics”.  As the BA has to work with both the business and information technology staff, they need knowledge of the organization, industry and technology.  What kind of personal characteristics would you want in a person that serves such an important role?  I am sure ethics and trustworthiness would make the top that list.

So if you’re a BA looking to advance your career, there are some competencies to work on.  If you’re an organization or manager looking to hire a BA, look not only at their skills and past performance, but develop some probing questions that will give you a look into their “underlying competencies”.

Where Does the BA Fit into Your Organization? Part two

Friday, February 19, 2010 by Aaron Whittenberger
In my last post, I joined the discussion of “where does the BA fit into the organization?”  I concentrated on the first line BA that should develop the enterprise architecture and help cultivate the business requirements for business process improvements.   This BA would be part of a combined Business and IT staffed Business Process Organization (BPO).  The purpose of the BPO is to analyze business issues and make the business case as to which IT business solutions projects should be undertaken. 

Once a project is approved by the governance body it is turned over to the Project Management Office (PMO) to guide the project to completion.  The PMO will be staffed with project managers (PMs) and business analysts (BAs) that will guide the project the rest of the way through the project life cycle.  You may be asking why you would need BAs as part of the PMO, or project leadership team; after all the PM is responsible to see the project is completed on-time, on-budget and on-schedule.  Yes, but the BA would be responsible to see that the project is completed and the IT business solution meets the business requirements.  A business application development project will need functional and technical specifications that the BA should help develop.

The third role of the BA, I alluded to in my first post on this subject, is that of the Test or Quality Assurance Analyst.  One role of the BA is to support the system, quality assurance and/or user acceptance testing phase of the project life cycle.

So the answer to the question ‘where does the BA fit …?” is in many positions within the organization.  It depends on which BA role you wish to discuss, and whether the organization is large enough to have a BPO and/or PMO.

Any thoughts on the subject?

Deploying JavaFX on Glassfish and Facebook

Thursday, January 21, 2010 by Matt Warman

First, sorry for the tardiness of my posts. Between the holidays, coming back from the holidays, a cold, and a secret project (for now), I haven't had time to blog.. until now. My current focus has been a Facebook game application. Well it's still in the alpha phase, but I wanted to get the architecture up and running. There's nothing worse for an application development person than to finish your application, then find out you need to rewrite it (or worse) because of the architecture doesn't support it. Even without Zembly, setting up a Facebook application is pretty easy. Since I had most of the defaults already in, the only thing I need to do is to tell Facebook where my application resides. Since I don't have Zembly anymore, I have to put on my application development and network administrator hats on set up an application server.
My first test was to deploy the application into my local Tomcat. NetBeans does a great job of having the files available to you, but the thing you learn quickly is that there isn't a simple deployment piece. Tomcat needs a WAR file, so I tried to use the JAR command to WAR up the files in the dist folder. No dice. The war file needs a proper web.xml file to work properly. Rather than use workarounds on workarounds, I created a web application project in NetBeans, linked the jar file from my JavaFX project, and copied the JNLP and HTML files to my new project. I now have a WAR to deploy. Tomcat loves this file. I run and... “FILE NOT FOUND?” was heard all throughout Cincinnati. Your JNLP file that was created points to a servlet called internally by NetBeans. Make sure change the following lines:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://your server.com/app path/" href="SBWarsTest_browser.jnlp">
<information>
<title>SBWarsTest</title>
<vendor>STAR BASE </vendor>
<homepage href="http://your server.com/app path/"/>

Once I made the change to localhost, everything was fine. Now I wanted a real application server, so I downloaded and installed Glassfish V.2.1 on one of our servers, changed the JNLP file and we are in business. I tried to hit it from my machine, and no dice. After some extensive research, I found out the the Java 7 EA JRE does not play well with JavaFX. I uninstalled it (which reverted to JRE 1.6.18), and it works. In Facebook, you need to set the canvas callback URL to your host application path. The result is the pretty picture you see at the top of my post.

Open-source Security A Major Concern for 2010

Friday, January 15, 2010 by Aaron Whittenberger

According to ComputerWorld, web application development remains top dog by far in the top IT skills to have in 2010.  Specifically, companies will look for developers with knowledge of .Net, Java, Web development, open source and portal technologies.  The article goes on to suggest that combining web application development skills with business analysis or project management skills is a big plus.  ComputerWorld lists the remaining skills to have for 2010 in its top six as:  Help Desk/Technical Support, Networking, Project Management, Security and Business Intelligence.

I feel ComputerWorld did not put enough emphasis on Security; this without doubt will be the biggest challenge for IT executives in the coming years.  Open-source software may be an innovative money saver, but IT professionals still have concerns that networks could be vulnerable to viruses, cyberattacks and other intrusions.

According to InfoWorld, a new survey from Forrester Research found that 58 percent of large companies have security concerns about open source. In addition, 57 percent of small and mid-sized businesses expressed concern that open-source software would be "complex and hard to adopt".

With the advent and increasing usage of open-source in the business world, expect to see demand for IT security related skills to grow.  According to the FLOSS 2020 roadmap presented at the Open World Forum in Paris, 40 percent of jobs will be related in some way to open source by 2020.  You can expect application development and security to comprise a great majority of these jobs.
 

IBM, Java, and the Community

Thursday, November 5, 2009 by Matt Warman

I recently read an article about the state of the IBM “i” and the amount of complaining by IBM application development and business partner folk. I know several RPG application development folk, and it sounds familiar. That made me think about my Java Application development and career. Are there things to complain about, and uncertainty about the future? Yes, but there are 2 reasons why the Java community is in a better place; the business model and the community. Before the IBMers call for a holy war, I said COMMUNITY! I am not talking about the strengths or weaknesses of the hardware or software. The business model for IBM is that they make the hardware and software, and partner for the sales and service. I think that is a viable model until IBM competes in the sales and services with their partners. If a lead is brought in by a small partner, they are awarded by giving the business to someone bigger. This sets up a confrontational relationship between IBM, the big partners, and the little partners. IBM can also decide whether or not you are worthy to be a partner. Why does this affect the software application development team? Because most consulting firm are selling SERVICES not HARDWARE. If they are not seeing business because of political fighting, they don't have to sell it. There are viable options on other platforms, where interference does not happen. IBM never fostered a community, they created a hierarchy with themselves as the head.

Certainly Sun has done some things that made myself and others unhappy. Besides, complaining, we actively pushed to remove barriers in our path. We do have an open source Java. Is there a IBM community that can work with RPG to make it work for them? I also think its about scale and timing. It's not like IBM software developers have their own AS/400 at their home. It's easy for me to create and use nearly any kind of application at my home in Cincinnati, and pretty cheaply. It makes it fun to tell non-technical people about my application development. Nobody but accountants want to hear about accounting programs. Java, and newer languages have grown up with the Internet. I have friends from all over the globe that have similar interests. If I have a problem, I can go online to a forum, friend, or web page to find what I need. I can read and write blogs to voice my opinion (like now). These things are not ingrained in the Legacy community, and in fact, have been actively campaigned against. It is my belief that any software, hardware, or service will die when there is no vocal community to support it.