Application Software Development

Most application software development team members are aware of and work within the framework of Project Scope, but few are aware of the importance of Solution Scope. Project Scope is usually defined by the Project Manager and defines the boundaries of the IT business solution project. It defines what areas will be in scope and what is out of scope for the project. Project Scope may also document the assumptions and constraints noted for the project. For example, an organization, with manufacturing facilities in Cincinnati and Dayton, is considering an enhancement to its customer invoicing application; the project scope could state that “this enhancement is to change the cosmetic look of customer invoices produced by the customer invoicing system”. It could state that this enhancement will affect only one, or a set, of customers and not other customers. The project scope statement should also declare what is out of scope for the project. Such as, “this project will not consider Order Entry and other Customer Service or customer complaint systems, as well it will not consider Accounts Receivable and other financial systems”.

The Solution Scope defines the new capability that the IT business solution will contain. The purpose of the solution scope is to conceptualize the recommended solution in enough detail to enable stakeholders to understand which new business capabilities an IT business solution will deliver, or in other words Create Shared Vision. By creating shared vision concerning the IT business solution at this point in the project you can decrease focus of the project to that solution scope, reduce scope creep, that can reduce project timelines and free up project resources sooner, increase stakeholder satisfaction at the end of the project. This increases the probability that the project will be deemed a success.

Take our example above, the solution scope will state exactly what is changing about the cosmetic look of invoices, such as “the company logo at top of the invoice will change to the newly adopted logo, the bill-to customer name and address will print to the right of the ship-to customer name and address on the invoice as well as the date printed will change to Day, Month, Year format (i.e. 15 August 2011) from its current Month, Day, Year format (i.e. August 15, 2011)”. Just as Project Scope declared what was out of scope for the project, the solution scope declares what is out of scope in relation to the IT business solution. “This enhancement will not change any calculations as to price or discounts that customer receives. This enhancement does not change how data is displayed on the invoice or how it is retrieved from the database except for the changes defined in this enhancement, meaning that item descriptions, quantities, unit of measures displayed will not change.”

So engage the Business Analyst early in and throughout the project to define and manage solution scope to keep the focus of the project, This helps the organization gain the many benefits stated above.

One of the primary responsibilities of some Business Analysts (BA), or Enterprise Analysts (EA), is to justify projects that the organization should undertake. The BA does this by creating a Business Case for the project and this task falls under the BA knowledge area of Enterprise Analysis. 

Many Business Analysts miss the ball in the Business Case by making the justification for the project or IT business solution very subjective. Many Business Cases start off with what the IT business solution should be. To understand what should be in a Business Case and how to develop one, we must first understand the purpose of the Business Case.

The Business Case is a formal written document to assist executive decision-makers in making the decision on whether to invest in a particular project or IT business solution investment. Knowing this purpose of the Business Case brings to light two important aspects of the Business Case: 1) it is for executive decision-makers and 2) it is to assist in their decision to invest. This means that two very important sections of the Business Case need special attention: 1) the Executive Summary and 2) the money section.

I have personally seen that executive decision-makers look at these two sections only.  Executives want to know 1) what is this about and 2) what is the cost and cost-justification. The Executive Summary should summarize the rest of the business case in a very concise and complete way for quick consumption by executives. The long, detailed version will be used by Managers, the Project Manager and other application software development team members. The second important section of the Business Case is the money. Notice, I not only said “what is the cost” but also “and cost justification”. The cost justification is what is usually left out of the Business Case; most Business Cases, even today, contain no ROI or cost justification analysis. The money section should contain not only the cost of proceeding with this project but it should contain a cost justification for undertaking the project. Projects can be justified by either a cost-benefit analysis, average rate of return, return on investment, internal rate of return or some other method of financial analysis.

Organizations may gain great benefits from engaging the Business Analyst in creating the Business Case including more informed decisions, project mix more strategically aligned and greater business understanding.

We will discuss the other sections of a Business Case and the process that the development of a Business Case should go through as this “The Value of a BA” series continues. Rich Larson of Watermark Learning presented a session on “Creating Bullet-Proof Business Cases” last spring at the Southwest Ohio Business Analysis Development Conference here in Cincinnati for Cincinnati, Dayton and other business analysis professionals in the region. Rich’s presentation, the BABOK® and other BA resources will be used to justify the concepts presented. I hope you continue to read and enjoy the series.

All enterprise application development team members know that an IT business solution project goes through a Project Life Cycle (PLC) from initiation through deployment and closure. It is also well known that the Project Manager plans the project during initiation to prepare to bring the project to a successful completion by ensuring that all application software development resources are available to the project when they are needed.
 

However, many people believe that the Business Analyst’s (BA) role on the project is to capture the business requirements for the IT business solution. Business analysis professionals know that there are Project Planning tasks for the BA to perform on the project.
 

The Business Analyst should be assigned to the project during the initiation phase about the same time as the Project Manager, assuming this is a different BA than developed the Business Case for the project.  If not, then the Business Analyst is already assigned and working on the project when the Project Manager gets assigned and should move from developing the Business Case to Planning the Business Analysis activities for the project.
 

Project Planning, or more commonly called Business Analysis Planning and Monitoring, includes planning the Business Analysis approach, conducting a stakeholder analysis, planning the Business Analysis activities, planning Business Analysis communication, developing a work breakdown structure (WBS) if necessary and planning the Requirements Management process to be used on the project.
 

Cincinnati and Dayton companies, as well as those across the globe, can benefit by engaging the Business Analyst during the Project Planning and gain reduced project timelines, better resource utilization, freeing up project resources sooner, less re-work and increased probability of project success.

Does your company engage the BA for Business Analysis Planning and Monitoring?

Another area that many Cincinnati, Dayton and other organizations across the country and internationally miss is utilizing the Business Analyst (BA) role in Enterprise Analysis, in particularly in giving assistance in “Project Portfolio Management”.

The goal of the BA in this role is to ensure that the proper mix of projects get approved through the organizational project governance body that best helps the organization achieve its short-term and long-term strategic objectives.  In addition the BA should ensure that there are no conflicting requirements or objectives of the projects being approved.

I worked for an organization that had a formal IT Steering Committee that considered each and every enterprise application development project proposed.  This IT Steering Committee was made up of the business leadership from all business lines and regions of the business and the Senior IT manager responsible for application software development within the organization.  The members of this IT Steering Committee would then rank the projects that were before the committee to determine which projects would get approved; those receiving the lowest ranking would receive approval.  Many organizations may have similar processes, whether they actually take a vote or not; but this organization missed the point because there were no BAs involved in this process.  The projects were presented to the IT Steering Committee by the IT Manager.  The process would have achieved greater results if the Business Executive Sponsor presented the project to the IT Steering Committee as they are most passionate about the business need and that the project would benefit them.  The BA would sit in support of the project as they did the initial analysis that provided the business need and the solution idea for that business need.

However, in this role the Business Analyst, or Enterprise Analyst (EA), would work with the IT Steering Committee or governance body to ensure that the projects receiving approval are the optimal mix of projects and helps the organization best fulfill its strategic objectives.  This EA would present to the governing body the strategic alignment and conflicting issues of the set of projects before the governance body and make recommendations as to the projects that should receive approval based on those criteria.

With this additional information the governance body can make a more informed decision to ensure the portfolio of projects that receive approval are best aligned with the strategic objectives of the organization and reduce the conflicting interests, requirements, issues and scope between the project.  This will help ensure that the organization meets its strategic objectives from year to year.

Does your company utilize the BA role to assist the IT business solution governance body in approving enterprise application development projects?

One of the tasks of a Business Analyst (BA) is Solution Validation, as it is defined in the BABOK®.  This is usually carried out by supporting the testing phase of the project once the entire solution or one or more features of the solution has completed development.  This would depend if you are using the Waterfall or Agile approach to application software development.

The BA should not be executing the testing of the solution, but be supporting the testing effort.  However, in reality in many Cincinnati and Dayton organizations, and organizations across the globe; with limited resources the BA is sometimes put in the role of actually performing the testing effort.  Whether they actually execute the testing or support the testing effort their main objective in this phase of the project is to validate the solution.  The BA accomplishes this goal by identifying acceptance and evaluation criteria, track and investigate issues that come out of the testing effort and performing root cause analysis on defects identified in the testing effort.

Take a step back from the testing phase of the project and realize that while the project was in the development phase, or slightly before, the BA should be engaged and preparing for the testing phase of the application software development project by preparing the test scripts.  In preparing the test scripts the BA should ensure that all the business and non-functional requirements of the solution get tested.  This process assists in providing requirements traceability from beginning to end; from stakeholder to solution.

In being engaged in this manner in the testing phase of the project, the BA can help ensure that the IT business solution meets the business need on an ongoing basis. This happens by reducing re-work, reducing the number of projects necessary, freeing up project resources and increasing the probability of project success as defined by the business stakeholders and project sponsor.

How does your organization utilize business analysts during the testing phase of the project?  Does your organization utilize the Waterfall or Agile approach for application software development projects?  Does your organization reap the benefits listed above of engaging the business analyst in solution validation? Please leave your comments to tell me how Cincinnati, Dayton or other business community organizations utilize the BA in the testing phase of the project.

Any application development team member, whether in Cincinnati, Dayton or other business community, knows that a software development project goes through many phases, known as the Project Life Cycle (PLC), and through many tasks within those phases.  These include: develop business case, develop project charter, develop project scope, develop solution scope, elicit business and non-functional requirements from stakeholders, requirements management and communication, risk assessment, develop project schedule, develop work breakdown structure, analyze current-state systems, develop future-state models, develop use cases, develop user stories, develop data models, development functional design, develop technical design, develop solution, handle development issues, test solution, facilitate user acceptance testing, implement solution, post-implementation support, handle production issues caused by solution, turn over solution to IT support team. (Quite a list, huh?)  Your list may be slightly different than mine, but I believe the essence of a project has been captured.

The Project Manager is responsible for the project and all these tasks, but to have one person be completely responsible for every piece of an application development project would be overwhelming and considerably increase project schedules.  This person would not only have to perform the management tasks but also communicate progress, schedule, risks, issues and more to project stakeholders. This can be very time consuming.  By placing a second person on the project to off load responsibility for some of these tasks (AKA Business Analyst), you can considerably reduce project timelines and more likely to produce better IT business solutions.  You can also possibly better utilize project resources by more effective management.  The Project Manager and Business Analyst are accountable to work together for project success.  By making the Business Analyst accountable for project completion and the solution meets the business need and making the Project Manager accountable that the project completes on time and on budget you considerably increase probability that everybody concerned will deem the project a success.

Can you pick out the Project Management and Business Analysis tasks out of the list of tasks above?

My esteemed colleague, Kupe Kupersmith, wrote an article for BA Times last week stating that “Agile is a Fad”. Now I know that will get a few of my other friends’ up in arms ready to defend their approach to IT project work. I can see the smoke coming out of their ears now. However, if you read Kupe’s article he says that “the word agile is a fad, the agile movement is definitely a trend.” I think it is safe to say that Agile is the hottest trend in IT project work these days. Many companies have switched over to Agile over these past few years and many more companies are considering the move. It has prompted many training courses by education providers. So let’s take a deep, hard look at the Agile “movement” and see if it is a fad, or is it here to stay? Is Agile really any better than Waterfall? What is the next best thing that will come down the pike?

Agile came upon the IT application development and software requirements arenas like a wave, gaining support as it moved. As education providers developed courses to teach IT application development teams to “go agile”, it gained momentum. All this happened in these past few years in very much Fad style. A fad starts very abruptly and gains momentum as it moves, forceful and overpowering; like a wave. Will Agile be here with the wave reverses course and heads back out to sea? This is where the fad loses its zest, when people realize that this is no better than what we had before, or it is swept over by the bigger and stronger wave of the next best fad to come down the pike. The wave reverses course and heads back out to see and disappears as fast as it appeared.  

Is Agile better than what we had before (Waterfall)? I won’t even go there because depending on who you ask, you will get a different answer. You could ask 100 people and probably get somewhere near 50 yes’ and 50 no’s.   That is built quite a bit on personal opinion. The one thing I notice with Agile as it is used today is that it is misapplied by many companies. They talk agile and think that they are using agile, but in reality they have adopted some of the components of agile, such as sprints, scrums and the daily stand-up meeting, but they miss the boat on delivering a piece of working software at the end of each sprint. When your five minute daily stand-up meeting becomes 15 or 20 minutes, all you really have accomplished is keeping your application development team from doing actual work. There are other places that say they are agile, but their sprint is six months long. According to the principles of Agile a sprint should be a couple of weeks to a couple of months long, with a preference to shorter timescale. So a six month sprint is not agile.

The biggest downfall to the Agile principles that I have seen in my experience is the need for comprehensive engagement of the Product Owner. In my experience, Business managers have a business to run and helping IT develop software is not in their job description, they don’t want to talk to the geeks. However, the smart Business managers know that if you don’t talk to the geeks, hard telling what you are going to get out of them. They need more direction than one sit down meeting saying “here is what I need”; and we will not go into the language barrier. If you can’t make IT understand what problem you are trying to solve, then you probably will not get the best IT business solution out of them.

So, is Agile just a Fad? Through all its misapplications and shortcomings, I don’t see agile going away anytime soon. It will not whisk away with the outgoing tide. Is Agile the “Be All of All”? There are some things that you just cannot develop with an agile approach. Some companies have developed a hybrid of the agile and waterfall approaches, so Agile is not the answer to all of IT’s business solutions problems. What will the next great approach be that comes down the pike? My crystal ball is not working today, but it is sure to hit the IT project management world just the way Agile did a few years back. Will IT management be ready for it? Only time will tell.

I recently blogged about our move to virtualized desktops. Well the saying that being a pioneer means getting arrows in your back is not entirely true! I have taken the plunge and have swapped out my work PC of 5 years to run Ubuntu. If you are a hard core Linux application development person, this post may be familiar, but as long time Windows user I was cautiously optimistic. Disclaimer, I have been a long time proponent of open source software and a fan “from afar” when it comes to the Linux desktop. I have used Linux and UNIX systems in the past, so the terminal learning curve was slight. This really isn't about the terminal, but all about the desktop, and how productive I can be. For the Windows based application development people and management unaware of Ubuntu, the desktop has a clean, simple feel, similar to Windows, but easier to manage. Instead of on desktop, I have four by default, so I can different applications in different spaces. What you know as the system bar is now a small strip at the top. Your chat and email notifications are in the upper right hand corner. This actually catches my eye better, Instead of a start button, the applications are in the upper hand corner. Linux applications have package information, so they can be grouped into categories. This makes finding specific programs much easier than Windows. I don't have to periodically go through the start reorganize anymore. I personally like a clean desktop, but for those of you who want shortcuts, you can do it in Ubuntu. Some applications can be found in the Ubuntu software center, a library of Linux packages. There are hundreds of apps to choose from, each within a category. You can search for specific titles too. All of the major technical applications have Linux versions, and I had no time finding and installing MySQL, Netbeans, and the VMware player. Ubuntu comes with Open Office 3.2, and Firefox 3.6, so I can surf and and open my Word document with ease. It found our work network, so I had access to all of our files. I have Wine, the Windows emulator installed, but I don't have any Windows applications running. Really, if I need that, I can use a Windows VM. As for the productivity, well my Windows application friends you'd be jealous. It takes 20 seconds from pushing the button to start to actually doing something on the desktop. It used to take 5 minutes. I had to change my routine, as I could start my machine and get some water downstairs before I could do work. My boss saw me open the Domino client in 10 seconds, down from the minute plus, and even he was impressed. I get updates daily, but I usually don't have to restart the system. Shutdown takes 5 seconds instead 2 ½ minutes. It's been 2 weeks since I switched, and I haven't missed Windows at all!

In an earlier blog post, I wrote about the dangers of working in IT. It is very important for application development people and really anyone who has a desk job to get regular exercise. My shocking moment was when I went to London with my son, and I saw myself walking across Abbey Road. There I am, and my “overhang”! To put more fuel on my weight fire, my boss is doing P90X. He has dropped several pant sizes and is looking good. To figure out how I was to lose weight, I did what all good application development people do, I observe what works for others. I recently read (and saw his picture) that Drew Carey lost 90 pounds in 8 months. His secret for his weight loss was getting on the treadmill for at least 30 minutes everyday, and eating broccoli. I looked at people who run regularly, and they are skinny! So I decided to run and eat broccoli. My diet currently consists of an apple in the morning, turkey for lunch, a banana in the afternoon, a protein shake after my run, broccoli, a small dinner, and maybe some skinny cow ice cream. This may be too much for some, but try these simple things to start: drink water instead of soda pop. Swap out a candy bar with a piece of fruit. As for the running, I go six times a week. I created a “course” at an executive park by my house. My first time, I barely got through a half mile. It doesn't really matter how far you go, just set a goal for yourself. Every day I wanted to go further, and eventually my course became three quarter of a mile. I found this Android app that is my favorite and most useful piece of software I have used. It's called Cardio Trainer. It uses GPS and Google Maps to track your running. It keeps track of you distance, time, and calories burned. I save my workouts, and now I have a history of my runs! In six weeks I am up to 16.5 miles a week while running three 5Ks in my training. I have lost at least 12 pounds (I am sure I have added muscle to my legs). My “overhang” has dramatically decreased, I have more energy, I sleep better, and I feel happier. The point of my story is that we application development folk need to get up and do something. If you have bad knees, try swimming. Find something that will make you active. Set a reachable goal, achieve it and set another one. I want you guys to hang around and read my stuff!

I know some of my application development colleagues my say “heard it”, but a virtual desktop is cool! We are currently running Windows XP as our company standard. We moved our 9 physical servers running Windows 2000 on ancient (and failing hardware) about 2 years ago. Most of our clients are currently on XP, but some are looking into moving to Windows 7, and one is going to Vista. When my application development friends stop laughing, they are doing this because they have certified their testing with Vista, and they will have to re-certify with Windows 7. They want to move to Vista now, and move again in a year or two.
We can just follow the Windows upgrade path, but given the success of virtualizing our servers, my boss gave me the green light to review our desktop strategy. Some application development and management people would say why? Well it gives us flexibility in what we can do. If we just move to Windows 7, and our clients are still on XP, then we are too ahead of the curve in terms of support. We do have some XP only development tools, so why not just keep them on their OS? With a virtualized desktop, we can run any OS we want. If our clients want us to run specialized software, we can set up an OS just for that client. The other big change is that we are using Ubuntu 10.4 as our host operating System. This is to reduce the memory requirements, but it has other great side effects. Our consultants can learn (at least the basics) of a new OS! If they are under constraints, they can fire up their Windows VM and get to work, or they can do the basic stuff (surfing, checking email) on Ubuntu. In time they can learn how to install packages and other tasks without disrupting productivity. The can even use Windows 7 and learn it too. The best side effect (for management anyway) is that we can still get a lot of mileage out of our 5-7 year old laptops. Our laptops have 2 gigs of RAM, so even if we went pure Windows 7, we would have a performance hit, especially when you fire up an IDE like Eclipse! The more I play with Ubuntu, the more I like it. I will probably use it as my main OS, but others can use XP, Vista, Windows7, or whatever we can virtualize. Choice is a great thing!

On of the big things all application development people know (and I guess business development people know as well), is how their department is treated by management. This battle has been raging since companies decided to have an IT department. The perfect company would have an IT department that supports the business goals and objectives, and can scale and change quickly. I can hear some application development folks laughter already. It can happen. Management needs to let the IT department make the decisions on the software, hardware and infrastructure. IT must understand the business needs, and managements' objectives. The business needs to articulate their needs, and help IT understand the business concerns. In balance, all departments fulfill their roles and the business grows. I have seen some companies that at least understand this principle, and try to implement it, but most companies have one side dominating the other. I will highlight the major factors for the Great IT Battle.

Management treats IT as a cost center – That is correct only if you are an accounting firm. IT brings great value to any organization by streamlining your business processes, which gives you your competitive advantage. I think that more than justifies the cost.

Business “owns” the IT department – This is very common where the business was mature before IT was around. Management came from the business, and doesn't understand that IT is a separate department. IT cannot scale and maintain their infrastructure, so once every 5 – 7 years there is a project like the Big Dig. If you like complex, over budget projects, continue in this manner.

IT “owns” the business - This is  common with organizations that see growth when they added IT. Usually this is caused by management thinking that IT solves all of the problems. IT supports the business. You still need a business plan and a vision.

Political battles between the three – This is the crux of the issue. Management usually comes from the business side, so when in a political battle, IT loses. Unless management views IT as the “magic bullet”, then IT wins. All political battles boil down to my next point:

Risk aversion - an executive at one of my clients pointed this out to me. All of the executives are the winners of many years of political battles. Any decision made is with the idea that they are near retirement, and will not make any drastic change that could hurt their position.

There are a lot of other factors that nuance these scenarios, so your view to the struggle is unique. We at STAR BASE would like to know where you are in this struggle by taking a brief (17 questions on 1 page) survey. STAR BASE can help your organization call a truce to the Great IT wars.

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.

I have been writing a lot about phones recently. What application development person wouldn’t be excited about the new smart phones? I will talk about that later, but first, the news!  My colleague Aaron Whitenberger has been interviewed about his role as a Certified Business Analysis here at STAR BASE.  If you didn’t know there was such a thing, you should read it now. I wrote my take about Google VS Viacom. Google spent 100 million dollars to defend their right, and it didn’t even go to trial. Vicacom is appealing, of course. The price of freedom is very steep.

Now on to my phone questions! A Java application development  peer my client site refuses to get a Android phone because of “market fragmentation”.  “I like that iPhone is walled off, but it’s on ATT”. He loves his blackberry, so maybe he doesn’t need it. This post from Slashdot  seems to support his case. My questions to you are why did you get a smart phone? Did you consider the operating system when you got your phone? Which would you rather choose, a fragmented but open system where you can get any type of app but could have bloatware, or an operating system ruled by a “benevolent dictator” which strictly controls your hardware and software, but you are free of bloat issues? I choose Android because of its openness. I do have the technical skills to root my phone to remove bloatware if I need to. Some people can’t or don’t. I think Apple went down this road before, and I think you will see Android be the market share winner. Let’s see if Google can do better than Microsoft in maintaining some control of  the platform, but still give 3^rd parties the tools to innovate.

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.

For those of you not following geek things, there is a lawsuit going on between Youtube (owned by Google), and Viacom (CBS, Daily Show, Colbert Report). Viacom is angry that some of their content was posted on Youtube. Apparently, there was 63,000 separate items on Youtube that were copyrighted by Viacom. Viacom has been supported with a “Friend of the Court” brief by NBC, BMI, and ASCAP (Basically the RIAA). Google has similar briefs by EBay, Facebook, Amazon, and Yahoo. How does this court case affect me as an application development person? Well, it could determine your web application development. There are many interesting issues here: fair use, piracy, site owner responsibility. The key issue here is for the very soul of the Internet. As you probably know, the Internet was created to share information amongst researchers around the globe. This communications device allows us to share voice, text, audio, and video. This makes it easy to share ideas, even if those ideas weren’t ours. A part of that communication is the same kind “water cooler” talk that everybody has done for years. “Did you see what that talk show guy said last night”? The only difference is now you can post it. This song expresses how I feel, and I have added some pictures to show how it has affected my life.
The media outlets want the site owners to control the content on their site. They claim that Youtube is a content provider, and thus are “stealing” their content for gain. This would be analogous to suing the U.S. mail for getting a threatening letter. We have fair use,  so any signal sent through the airwaves is free for anyone take and use. This meant that anyone who broadcasted, the content could be consumed by anyone. The content providers made money by placing advertisements in the content. Since that time, content providers have been using congress to side step these boundaries by changing the length of copyright, putting "digital" rights on formerly analog content, and pushing for laws that allow content to be controlled by the provider. The large media companies ignored the Internet because there wasn’t any correlation to their business. When companies like Google started to compete for the same advertising dollars, the large media outlets saw the Internet as a threat to their business model, and are now looking to destroy it.
No one is trying to deny content providers money. It was agreed long ago that your work was yours, but eventually it would be owned by the public. That changed when media companies are entirely built upon their own content (just look Mickey Mouse at Disney). Do people take content that doesn’t belong to them? Yes. Are people just posting items broadcasted to make their point, or to inform? Yes. We have to decide as a society whether the Internet is place to allow copyrighted material as a form of communication. NBC found it distasteful that their shows were on Youtube. That’s why they created Hulu.

What do you want the Internet to be, a free (as in liberty) communication device, or a pay-per-view broadcast medium?

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.

I have a new client in Cincinnati. New clients are always interesting because you never know what issues and opportunities you will find. My client seems to have their act together. My application development friends will appreciate their setup; Maven 2 projects with built-in JUnit tests, a code coverage dashboard that show code complexity, code coverage, and Find Bugs reports. Things seem great, them why do they need a performance engineer?

The reason is common; who defines the duties of ITsets the rules. IT and the business need to be aligned to work on the common goals and increase productivity. If IT is too dominant, there is too much focus on technology and the business doesn’t get the tools they need to be productive. If the business unit is dominant, only projects that have a tangible return get done. In this case the business is more dominant, so projects like refactoring code, or cleaning up errors found by software like Find Bugs has a much lower priority. They do happen only if performance is an issue to the business. The performance team is set up like a clean up crew that comes in after the fact, to make things work better. There are coding style forms and best practices, but is up to the each developer to follow them. Since the focus is getting the project done on time, the developers are concerned on getting code that works,not what works best. The performance team is used to fix the worst performance offenders.To be fair, I have been at clients where IT treats the business units as a nuisance. The best tools are there, but little support for the business.
What’s the solution? IT needs select a technology that best suits the solving of business problems. The business should prioritize their issues, but work with IT to plan for fix releases. IT must utilize the tools that they have and encourage the usage of them. If you have the tools, use them!

• 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

This post may shock you... the Java Rocker is going to talk about legacy iSeries and AS/400! Before you panic, and call it the end of the world, let me continue. This post is about running all of the cool new Web 2.0 things on your IBM hardware. Really! Even in Cincinnati! Many people, (myself included) thought the old IBM hardware was only for RPG and COBOL (shudders). It turns out that IBM has been adding functionality to run Linux on the box. That means Wikis, Ecommerce, blogs, and web applications are now there for iSeries-AS/400 people. The catch is that your iSeries needs to be up to date, which sadly for most organizations is not. My IT consulting colleagues at STAR BASE are good with taking your tired old hardware and doing the maintenance necessary for the modernization piece. They get your hardware and software cleaned up and ready, so I can help you with all of the cool new application development projects that I have been talking about.