Enterprise Application Development

BA: Creating Shared Vision

Monday, July 19, 2010 by Aaron Whittenberger

I am often asked what is a Business Analyst, what is the role of the BA or what does a BA do? Of course, those questions can be answered in many different ways that usually begin with the old standby answer “It depends…”.

When answering those questions, as with most BAs, I will get into the role of the BA within the organizational structure, Enterprise Analysis vs. Requirements gathering on a project, tasks and techniques. I go beyond these limited explanations and try to answer what I believe the requester is really asking “What is the goal of a BA?” I believe the goal of all business analysis activities, whether it is Enterprise Analysis or Requirements Gathering, should be to create a shared vision among the stakeholders.

Create a Shared Vision

Creating a shared vision is much like painting a picture. You are painting a picture in everybody’s mind so clear that everybody can see and understand the picture. No, painting

is not one of the tasks of business analysis. You paint a picture with your words and documentation. Text documents, flow diagrams, use cases, storyboards, activity diagrams, business process models, wireframes and other mockups can all be used in paint a picture. These can be used in combination to paint an even more vivid picture for your audience. Sometimes, as in requirements elicitation, it may mean that you gain the vision of the stakeholder. If in a requirements workshop, focus group discussion or one-on-one interview, drawings on paper or a whiteboard can facilitate shared vision and understanding. Often, it may be that you paint the “as-is” picture for the business stakeholder(s), and then they paint the “to-be” picture for you. By painting a picture so vivid that all stakeholders share the same vision of it, this is how we build the bridge.

Target the Vision to the Audience

In order for your audience to gain a vision, they must not only see the picture, but understand it. The picture must be painted in a way that facilitates understanding; it must be presented in a way that the audience can comprehend. You may use flow diagrams, use cases, story boards and/or activity diagrams when painting the vision to a business audience. You may use text documents, flow diagrams and/or activity diagrams to paint the picture for a technical team. You may use very short summary text documents and/or flow diagrams to present to management. To create a shared vision the picture must be presented in a way that facilitates quick comprehension from the audience to whom you are now presenting.

Sell Your Vision

Not only in our business analysis tasks, but in work outside of business analysis, we must create that shared vision; then be ready to talk about the vision and ensure that all see the same vision. Adriana Beal writing for Bridging the Gap, talks about successfully selling your initiatives to management. As Adriana writes, understand your manager’s framework and persuade your audience not only to accept your point of view, but to act upon it. What she is describing is painting a picture so vivid for your manager that they gain a shared vision with you and that they will want to take immediate concrete action on your proposal.

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.

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.

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.

Use Cases with UI and Details

Monday, May 17, 2010 by Aaron Whittenberger

How many times have you developed Use Cases for a project, gone over them with the stakeholder, reviewed the functional requirements of the system, developed and delivered your IT business solution to have the stakeholder want to make changes to it immediately? Is this a symptom that the stakeholder did not understand the Use Case?

More then likely what the stakeholder did not understand is what the user interface (UI) would look like or how it would act. So then we as Business Analysts (BA) turn to Microsoft Visio, PowerPoint or some other tool to create a mockup or prototype of the UI. We share that with the stakeholder, but he/she is still left without the whole picture.

So now we as BAs turn to Microsoft Word, PowerPoint or some other tool to put some details behind the Use Cases and UI. We share that with the stakeholder and get their approval to build the solution. So back to Microsoft Word we go and write a high-level and eventually a detail design to give to the developers to build what we have laid out to the stakeholder. Now all of sudden you three to six documents that you must track and keep in synch; a change to one document may mean a change to another.

Masayuki Otoshi gives a solution to this dilemma in a BA Times article as storyboarding; a way to put Use Case, UI and detail specifications in one document. The article shows an example of user login webpage. It gives examples of the main stream, providing a correct user name and password and an exception stream, providing an incorrect user name and password.

On the surface storyboarding to provide UI and detail information to the stakeholder sounds like a good idea. The simplicity of the example falls short to show the usefulness of this tool. I deal mainly with complete Enterprise Resource Planning (ERP) systems and eCommerce website interfaces to the back-end order fulfillment system. Using storyboards to show the stakeholder(s) what the eCommerce webpages or the ERP desktop screens will look like before they are built allows the stakeholders to make changes to the look and feel of the system before development dollars are spent to build it. Giving the stakeholder(s) a more complete picture of the proposed system look and functionality during analysis and design phase of the project should reduce the amount of rework requested.

Storyboarding has been used in the Agile system development methodology for awhile. It has not caught favor in the SDLC or Waterfall methodology as of yet; but the need to draw a more complete picture to the stakeholder(s) of a proposed IT business solution as early as possible in the project cycle may give storyboarding the light of day.

I do see the usefulness of storyboarding for the SDLC as well as the Agile methodology. I look back on past projects where I could have used storyboarding, if nothing else, to decrease the project schedule.

I do raise one word of caution…remember your audience. All too often I have seen IT business solutions project teams try to combine multiple documents to serve several purposes. Giving the stakeholder(s) the level of detail that developers need to develop the solution may cause confusion with the stakeholder. So do not try to combine everything into one document. Even your wording should be different for stakeholder documents and technical documents. So try storyboarding if appropriate to the project. Someday we just may find it as mainstream as requirements documents and Use Cases are today.

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:

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

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

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

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

Building the Business Case for New Tools

Friday, March 26, 2010 by Aaron Whittenberger

A couple of weeks ago I wrote about the need to develop a Business Case document. Soon thereafter I find this one-page Business Case document. The first question that comes to mind is “how can you put all that needs to be in the Business Case document in one page?” Believe it or not, they did it. Of course, a lot of things were abbreviated. You have to question the usefulness of such a document.

Of course, a one-page document is not what we experience in our IT Business Solutions projects today. Instead, we have what Chris Gurney wrote for BA Times as the “Big Freakin’ Requirements Document”. Chris outlines the various reasons that our requirements document has to be so freakin’ long:

To Communicate to all audiences
To Validate that Needs are Met
To Ensure Everything’s within in Scope
To Manage Changes to Requirements
To Meet Regulatory and Corporate Obligations
To Define Requirements Collaboratively

It has become common place in over the years to try to accommodate everyone with one document. So language is included for executive staff. Then we translate the requirements to a more detailed level for developers and testers. We turn on “Track Changes” feature to retain the history of changes to the document; which then leads to descendent versions of the document.

What Chris is trying to point out in the article is that a Word document is no longer sufficient for collaborative development of requirements for our IT business solutions projects. What you can expect to see is many vendors rush to provide software solutions to these shortcoming

s. Currently, there are some solutions out there to address these issues. I will not promote any current software solutions here, but you can expect to see more solutions from new vendors in this area. You will also see great improvements in features in the solutions that are already on the market. When business organizations migrate in groves to these solutions and away from Microsoft Word as the standard for “document” development then you will see this market grow rapidly. Large organizations with large IT staffs and geographically dispersed enterprise application development teams should be first to make the move. I think you will see Business Analysts within those organizations leading the charge, but with all “organizational shift” changes, convincing those that hold the purse strings of the value and need for new tools will be their greatest challenge.

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.

Building the Business Case for the Business Case

Thursday, March 11, 2010 by Aaron Whittenberger

In a BATimes article John Moore visits the need and proper use of a Business Case document to increase the success of IT business solution projects. He demonstrates a failed project due to a competitor who released a competitive product in the market before our organization’s project completed. The business manager showing the project failed because it did not deliver the projected ROI. The IT project team noted that they delivered the project on-schedule, on-time and on-budget. Was that risk that a competitor could beat us to the marketplace identified at project initiation or during the life of the project? Were the proper stakeholders identified and included in the project communication plan?

John makes note how the Business Case document should be revisited several times during the project life cycle. Doing so may have caught the changing environment and allowed the organization to mitigate the risk from the competitor.

John makes very valid points that I believe show an improper IT solution Project Delivery System. Laura Brandenburg notes in her blog that the Business Case document is often created under another name, or as I have noticed in many organizations the Business Case document is created, then it is used to develop the Project Charter and Project Design documents. These documents should not only be created but needs to visited by an IT Governance body during multiple steps in the IT solution Project Life Cycle; not just at project initiation. At each point it makes a “go/no go” decision as to whether to continue the project. This is where many organizations fail to follow through.

Take the simplified high-level Project Life Cycle that includes 5 phases: Initiation, Analysis, Design, Development and Implementation/Closure. Most organizations will make the “go/no go” decision on an IT business solution project either prior to the Initiation phase that kicks off the project or at the end of the phase, depending on how the organization defines its Project Delivery System. In most organizations that is the only time that the IT Governance body will rule on the value of the project.

If the IT business solution project had to go before the IT Governance body at the end of the Analysis, Design and Development phases as well as the Initiation phase then the organization has greatly increased its ability to mitigate risk in the project, especially from external forces.

As the project goes through each phase of the Project Life Cycle, the benefits, costs, requirements and risks are further defined. In John’s example, if our competitor launched their product while we were still in Design then our IT solution project went before the IT Governance body for its next “go/no go” decision. The IT Governance Body, being aware of the competitor’s product launch, can now say that the project benefits are no longer valid. The risk mitigation plan can be executed, which may include dropping the project all together. This reduces the cost to the organization as those resources can now move on to a more valid IT solution project.

So not only is it important to make sure that you build a Business Case document, by whatever name you may call it, but be sure it is visited several times during the project life cycle, by others outside of the project team, to ensure that the assumptions (benefits, costs, risks) therein contained remain valid. This along with making sure the proper stakeholders are involved greatly increases ensuring that the IT solution project maintains its value to the organization.

Business Analysis: Building the Bridge

Wednesday, March 3, 2010 by Aaron Whittenberger

A common reference I hear in business today is that the Business Analyst (BA) is the bridge between the business and information technology staffs within the organization. This infers that the knowledge of getting from one to the other, or interacting with either is contained within the BA alone. The BA should not be the bridge, but the bridge builder. If the knowledge is contained only within the BA, if the BA should leave the organization, then the bridge is gone. If the BA is the bridge builder, then if he/she should leave, the knowledge remains within the Organization.

As an IT Strategy Consultant developing IT solutions here in Cincinnati and Southwest Ohio, I go from organization to organization and see that turnover within the BA ranks inevitably causes a great learning curve; either to recover the knowledge that has just walked out the door or bringing the new BA up to speed and making them an effective contributor to the organization.

What all these organizations lack is an Enterprise Architecture, a fundamental artifact of the Business Analysis profession. This and other artifacts are the foundation of creating a Business Analysis Center of Excellence. There is a maturity path that all organizations take from having a community of BAs that serve the organization with no continuity or conformity of service through a mature level in which that continuity and conformity of service is establish; into a BA Center of Excellence, where all BAs within the organization have a common standards of practice, tools and resources from which to draw knowledge.

Where is your Organization on the maturity path to a BA Center of Excellence?

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?

Testquerade Part One.

Thursday, February 18, 2010 by Jeff Welsh

I had lunch today with one of our Cincinnati customers and he made the comment that his company had eliminated a lot of costs via their IT applications. He also said there was no more low hanging fruit in their IT applications. Everything is integrated and there are no easy changes. I laughed and said there is nothing easy any more; even my easy button quit talking!

In today’s world some IT applications have grown quite complex. It was not that long ago an application developer that knew business could do the business analysis, the technical design, program the application, test and implement it.
Enterprise IT applications today require a team of dedicated professional working together and a good process methodology. Many members of the team are specialized in a particular skill or a part in the development process.

One of the things that is sometimes overlooked or gets glossed over is testing and quality assurance. I have even heard developers say “why should I test, that’s what we have users for”. Because systems have become so integrated and complex, quality assurance is not something to be taken lightly. As a matter of fact, it is quickly becoming a specialty in and of its self. There are many aspects to quality assurance, but one that I think we will be seeing a lot more of in the coming months and years is the notion of Test Data Management. To be continued……….

Where Does the BA Fit into Your Organization?

Monday, February 15, 2010 by Aaron Whittenberger

I attended the CIO Speaker series sponsored by the Cincinnati Chapter of the IIBA^®. The January meeting showcased the CIO and Deputy CIO of FirstGroup America. It was not part of their presentation, but a question was asked of them “should the BA report to IT or to the Business?” This alludes to the bigger question “where does the BA fit into the organization?”

This is the question that many organizations are still trying to answer today. Many organizations are just realizing the benefits of the BA role. One thing to realize, is those of us in the BA arena today are in the forefront of an infantile and growing profession. The International Institute of Business Analysis (IIBA)^®, the professions governing body, was formed in 2004; incorporated in 2006. There are 827 certified professionals (CBAP)^® in the world. Compared to the Project Management Institute (PMI)^®, which was incorporated in 1969, offer five certification programs and has nearly 300,000 certified professionals. You may say that your company has had BAs for the last 5 or 10 years. Then I say your company is one of the forward-thinking organizations that has recognized the benefits that the BA role provides in developing IT business solutions.

Now I believe this discussion will go on for years; but as this is my blog, here I get to put my two cents in. First, let’s define the role of the BA in which we discuss. Many organizations have a quality assurance team, department or processes within the IT application development team. As these people support system or user acceptance testing procedures, these people are Business Analyst. For this discussion, I refer to the Business Analyst that works on the front end of the project life cycle. Who develops the Enterprise Architecture, gathers business requirements for business process improvements and makes the business case for IT business solutions projects to make those improvements.

As the role of the BA is to develop requirements and make the business case for IT application development projects, this is an IT function; therefore the BA is an IT position and should report to the IT management as opposed to the Business management. Although the duties that the BA performs may put him/her in front of external customers of the company, their goal is not to perform the business of the company but to recommend IT business solution projects to improve business processes within organization; this is an IT function.

If your organization is large enough to use terms such as Business Process Organization (BPO) and Project Management Office (PMO); then you should find the BA at the heart of the BPO. The purpose of the BPO is to analyze and recommend improvements to business processes. So now you say that in most organizations the BPO is a business team; I would reply that it should be a combination business and IT team. The improvement to business processes may require a business solution, such as upgrade or replace business machinery or training; or an IT solution, such as application enhancement, system training or system upgrade. Therefore, the BPO should be made up of business positions and IT positions working together to determine the best solution to business issues.

One thing that I would change in many organizations is that I believe the BA should sit more in the vicinity of the business unit(s) that they support as opposed to sit in the IT Department. BAs will be much more effective when they fully understand the business processes in place, issues that business workers face and the daily going-ons within the business unit(s). Also, easy approachability to the BA for the business gains buy-in to the duties and recommendations of the BA.

So there is my opinion on the subject, what is yours?

JavaFX + JPA = Awesome

Friday, January 29, 2010 by Matt Warman

Yes, this is another of my continuing series of JavaFX posts. I hope you are enjoying the posts, and hopefully you will take a look at JavaFX, because it's really going to be a great platform. One of the key complaints from some application development folks is “yea it does cool animations, but where's the non-trivial uses?”. True there has been a lot of “toy” applications, some touted as “Enterprise”, but I want to give you a key usage for your business application development.
First off a brief primer on JPA, or Java Persistent API. The technology grew out of the complexity and (loathing) of the EJB 2.0 spec. Hibernate came up with way to use POJOs to persist data. The brains behind JPA were the driving force behind JPA. Now is the time to learn JPA, because it's a big part of the EE 6 spec.
Some notices here first; I am using NetBeans as my IDE. You should be able to use the general theme with Eclipse though. JavaFX can use Java classes in the script. The key part for me was how to integrate them. The easiest thing to is create a new Desktop application project (New Project → Java → Desktop Application). Pick the database application, so the JPA wizard displays. Select your table, and the wizard creates the JPA controller, and all of the Entity classes for you. Run the Build project, and now you have a JAR file. If you don't have NetBeans, or want to do this by hand, create the Controller and Entity classes and put them in a JAR file. Add the JAR file to your JavaFX project path, and your ready to go! The following Code can be put in your script to access:

 var db =  new YourTableJPAController(); //Creates a new instance of your controller 
 var list = db.findYouTableEntities();  // find all of the entities of your table.

To display all of the values, you can run a for loop like this:

 Vbox {  for(y in new YourTableJpaController().findWineEntities()) 
     Text {  	    content: y.getField() }	
 }

The code above iterates through the List object created by findYourTableEntites, and puts it in a Vertical Box (Vbox). Each item in the Box is a Text object whose display value is one of your fields from your table.

You can now dynamically populate your fields from a database, but more importantly, you are using JPA to handle all of the heavy lifting. Notice I didn't mention anything JDBC. I let JPA do all of the communicating with the database. This is a layer abstraction that let's be an application development guy, not a DBA or Network Admin (not that there's anything wrong with that). If you are using an application server that handles JPA like Glassfish, then you can make your JavaFX application available on the browser and desktop. Now you can have that awesome looking application that actually does something. You are happy to start doing something cool, and your boss is happy because it does something he wants.

ROI, Do we have to?

Tuesday, January 19, 2010 by Jeff Welsh

Happy New Year!!! Welcome to a new year, new decade and a new beginning.

As the recession recedes and recovery takes hold, IT executives are looking at their project lists and trying to decide what their priorities are. Should we do application development in house or bring in an IT consulting company? Should we consider an open source application? What is the ROI? What’s a company to do? It doesn’t matter if your company is in Cincinnati, Dayton or Katmandu, the questions are the same.

Last month we did a pulse survey to see how IT leaders are managing ROI measurement. The results were surprising and sparked a lot of conversation here at STAR BASE, Inc. The thing that surprised us the most was the number of companies that did NOT look at ROI before doing a project. Most of our respondents (58%) do not.

Some of conversations we have had revolved around the idea of doing a project or installing an application just to stay in the game. Could you imagine a company of any size today functioning without email? I could argue that there is negative ROI with amount of time managing my email in box takes!

For those that measure ROI, only about half see the actual ROI align with the projected ROI most of the time. The other half report that they see the actual ROI align with the projected ROI less than half the time and most said seldom or never. I have often said that if management knew how much it was really going to cost to install that new ERP system before they started, they probably wouldn’t.

Since most of our respondents don’t look at ROI and of those that did, half said the ROI did not align, my question is this: How do you decide what projects to do? Are most companies spending money on IT because they need to “keep up with the Jones’ “? Is it because installing that new ERP will look good on everyone’s resume?

Get your copy of our ROI Survey results by going here.

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.

Is IT Qualified To Satisfy The Business?

Monday, November 9, 2009 by Aaron Whittenberger

“IT executives increasingly implement marketing initiatives to improve the communications with their business customers. But these efforts often focus solely on the brand aspects of the services under the IT’s control without understanding the business’ perception of IT. To maximize the success, IT must add business satisfaction assessments to its tool kit. Understanding business satisfaction requires qualitative and quantitative data that capture customer expectations and perceptions through different types of interactions such as interviews, panels, focus groups, complaint systems, and surveys. This report provides best-practice recommendations, survey templates, and questions to guide IT executives through the deployment of a business satisfaction assessment. It applies Forrester’s deep expertise in external customer satisfaction to the interface between business customers and their internal IT suppliers.” says a new Forrester report.

I have served on countless business application development teams within several organizations in the Southwest Ohio and Cincinnati Information Technology community, one thing I can say is that most IT organizations do not gauge business satisfaction with IT business solutions. I have served in only a couple of organizations where the business serves on the IT governance committee. An organization does not have to be “big” to have an IT governance committee. No matter what the size of the organization decisions are made as to priorities in IT work. IT governance does not have to be a long drawn out process or take great time commitment from the business or IT executives, but business involvement in IT governance goes a long way in gaining business buy-in as you roll out the IT business solutions to the business.

Involvement in IT governance is just one way that many organizations in the Greater Cincinnati area can improve the IT-business relationship. The Forrester report goes into ways to solicit and gauge business satisfaction with IT business solutions. Doing so should affect decisions concerning not only IT business solution delivery but also IT Infrastructure and IT outsourcing initiatives.

Kenai Me!

Friday, September 11, 2009 by Matt Warman

I have not one, but two JavaFX Kenai projects found here and here. First, I have to say Kenai is very useful. It is integrated into NetBeans (my IDE of choice), which means that all I have to do is create a new a project and call the “share it on Kenai” link. The process allows you to change the name of your project, and set the licensing (CDDL, GPL etc). Kenai itself is pretty cool too. It’s not your father’s forge. First off, anytime anyone commits a change a message gets sent out. That may not be earth shattering to you, but if there is more than one person in the code that is huge. I don’t have to guess who changed what. Since my email is tied to my phone, I find out almost immediately! You can do things other places offer like a forum, and mailing list, but the clean execution is nice. It is easy to find on the main page, and any responses in the forum go to my phone! The social networking aspect is something that I want to use. I live in Cincinnati, but I have friends all over the world. If someone helps me out on a project, I can chat with them through Kenai. The price is the best part my application development friends, free. When you sign up to Kenai, you get five free projects slots. I don’t know what happens after five though. I encourage all application development people to put their passion projects on Kenai.

FUD Factor

Tuesday, September 1, 2009 by Jeff Welsh

A couple of weeks ago, I made the trek to Columbus and attended the Ohio chapter meeting of TechServe Alliance of which STAR BASE, Inc. is a member. In talking with other owners and corporate executives, everyone is pretty much saying the same thing: “We are seeing more sales activity, just no commitments.” Seems like everyone involved with Ohio Information Technology firms is in the same boat. In Cincinnati, things might not be quite as bad as Columbus because there is less state government work.

So why is there a lack of commitment? There could be many reasons, but it all boils down to what I call the FUD Factor. Never heard of the FUD Factor? We would not be a real IT Consulting firm if we couldn’t use a TLA (three letter acronym) and it’s not what you’re thinking! FUD is short for Fear, Uncertainty and Doubt.

When the FUD factor is high, people tend not to make commitments, changes or decisions. Doing nothing seems like the safest choice. A high FUD factor equals RISK and as a society, we have become very risk adverse. When the FUD factor is low, decisions are much easier to make, less risky.

With the economy down and so much uncertainty, the FUD factor is definitely high. So is doing nothing really a good choice? Things tend to move in cycles or patterns, it is the way of the world... Losers become winners. Winners become losers. Day yields to night; nights divide the days; summer gives way to winter. Life goes on...always as it always was...but never the same.

Will you be ready?