Information Technology Consulting Services

Seven Deadly Sins of Consulting, Part 2.

Monday, July 26, 2010 by Jeff Welsh

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

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

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

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

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

Seven Deadly Sins of Consulting, Part 1.

Friday, July 23, 2010 by Jeff Welsh

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

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

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

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

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

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

BA: Building Maturity one Building Block at a time!

Monday, June 28, 2010 by Aaron Whittenberger

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

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

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

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

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

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

Don't Repeat Yourself (DRY)

Monday, June 21, 2010 by Mark Murphy

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

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

Roaming the UK

Monday, June 21, 2010 by Matt Warman

In my recent post, I talked about my new phone for my upcoming trip to London. I am excited about my new phone, but not the cost. My carrier charges .35$ per outgoing SMS, .20$ per incoming SMS, and 15$ per MB for data. Since my phone is always “listening” on the Internet, it would cost a lot to actually use my phone in London. I can put my phone in “airplane” mode and use the camera, games, and music capabilities, but why have smartphone and not use its features? Fortunately, the solution is relatively simple. I can unlock my phone and use a pre-paid SIM card while in the UK. For my application development friends who are not phone savvy, let me explain. US phones are “locked” for US usage only. All carriers also make some phone features unavailable to the customer. In some cases, you are charged an additional fee for a feature your phone could perform for free! In this case however, I am unlocking my phone so I can use it on other networks. You may have heard of the term “Jail Breaked”. This refers to a phone that has been hacked to allow all features on your phone to be used. Some phone manufacturers and carriers don’t like this, and can make your phone unusable, or “Brick” your phone. Unlocking through your carrier is perfectly fine though. Once your phone is unlocked, the second part is to get a SIM card in the country you are traveling to.The SIM card is how the network recognizes you. If you opened your phone and swapped your SIM card with a friend, you would get all of his calls, and he would get yours! You can pick up a prepaid SIM card with a data plan for about 10 pounds (approx. 15$) a week. That’s a hefty monthly bill for a local customer, but it is much cheaper than the roaming plan. Remember, your phone number is different with a different SIM card! I can use my phone features to post messages and images on Facebook, for example, like I was at home. I can communicate with people at home without paying hundreds! I will let you know how this works out when I return.

The Secret to Good Performance

Tuesday, May 11, 2010 by Matt Warman

I am now in my second stint as a performance architect. There are many tools to measure performance. Usually there is some criteria like time or memory that is failing. I think most application development people know that the secret to good performance is good code. The problem is that good code is impossible to measure. There isn’t any metric you can show your boss that shows refactoring this class will make the code run faster, or at least will not remove that class from the performance list. Besides we have these new features that need to be added. So how do I make code perform at a high level?
Write unit tests. Make sure that the tests cover all of your method calls. Make sure that your test captures error situations, not just the "happy path". Write your test cases BEFORE you write your code so you can "code to the test". Of course, you need good use cases from your architect and business analyst to write the unit tests.
Comment your code. Make sure your method names describe the function it is performing. Most IDEs add the parameters and returns for you; all you have to do is describe the reason for the method. These are easy things to do. They are boring yes, but when it comes to adding that new feature, or changing a method call, it saves a lot of time when you can run a test to prove that your changes work.
Refactoring. All application development people should learn refactoring. The Java language has changed tremendously in the last 15 years, and your code hasn’t. I think that the Date object has been revamped twice since the 1.x days. New features like annotations and generics may not change the performance of the code, but it sure does affect the readability of the code. Readable, easy to understand code is also easy to maintain and update. It makes a six month project become a three month project. The business always has more projects, so they will be happy. Fewer errors happen, so your boss is happy. You get to solve more interesting problems so you are happy. When you are happy, both you and your code performs better.

Death by A Thousand Cuts

Wednesday, May 5, 2010 by Matt Warman

My client has great code promotion rules. All code that changes gets system tested or it doesn’t get promoted. Code doesn’t change unless it has a bug tracking ticket. You say Matt, that’s great! Why is this a problem? The problem resides in the fact that everyone in IT is stretched to the limit, and deadlines are tight. Application development people are getting the code working with little refactoring, architects struggling to get the analysis piece out and little time for code review, and not enough testers. This situation makes it difficult for performance. As part of the performance team, I can review all of the code, and make some changes, but the problem is that if the code is not a part of the release, it will be impossible to get promoted due to time/resource constraints.
For example, a process was taking a long time to complete because of improper error handling, but the call is not necessary. The proper fix is to remove the call, but the fix going in only resolves the exception. Why? The low priority of the code, coupled with the testing constraints and lack of testers makes these changes common. Some application development people may say, "Well, the code is fixed". True the performance issue is resolved, but there is an unneeded call. If the attitude from application development people is "I would fix it, but it’s too much trouble to test", unneeded code can add up quickly. Extra code is in all projects, but if changes like this or, removing a variable passed to a method, or even changing code to remove unused variables don’t get fixed, the "extras" add up. Not one of these changes significantly affects performance, but all of them will. The solution is to work with management and your application development people to limit "extra" code. This can be done by reviewing and fixing code in your maintenance or enhancement project. Have a "refactoring time" built in to the project plan. The time put in up front will bring great dividends both in performance and future coding effort.

Getting Some REST

Monday, April 19, 2010 by Matt Warman

After playing with JPA, I realized that I really don't want to directly hit the database from the client, because that would mean opening up the database port to potential attackers. JPA is really great, but either you hit the database locally, you hit the database directly from a remote location, or you access the database through a connection pool. JNDI is the best way to access a server resource, but it needs to be in a server container. I could not find a way to call JPA using a JNDI context from the client. All database servers have some mechanism to accept multiple connections. But besides the obvious security issue, I already have an application server and connection pool. I should let the connection pool do the work, and figure out plan B.

I reviewed all of my options. I am lucky because I can use the latest and greatest since this is all new. I am using Java 1.6, so I can use EE5 or EE6. Most application development people know that EJB has had a history of being complex, and at times, unwieldy. I could call JPA via servlet, but I was concerned about performance. I decided to use RESTful web services to push data to my JavaFX application. Using REST in JavaFX is quite easy, because the 1.2 specification has a HTTP request object. That means I can write all of my access and utility objects in JavaFX, instead of accessing a class library externally. The big drawback I have thus far is that all of the related objects are another link, and another call to a REST resource. For example, if you look up a specific Customer Record using REST, you will get the details in XML or JSON. To get the collection of Orders related to the Customer, the XML returns a link. You must make another call to get another XML/JSON to parse the related information. The parsing process would not be to big of a deal, except that everything is done asynchronously. I have a Table A object where one of the fields would be a collection of Table B objects. The Table B object contains a collection of Table C objects. In JPA, all of the related collection objects are there and ready for me. Since REST is asynchronous, It makes it very difficult to set up a Table A row object, because Table B is a separate call which will start and finish without Table A's call knowing anything about it. For my database application development people, the key is to de-normalize your relationships. Since this is a big departure to my original schema, I decided to create a whole new database in case I wanted to go back to JPA. After some trial and error, I have a way to asynchronously access and display REST resources in a JavaFX application. I now have to work on writing that data.

The Rat Race?

Thursday, March 25, 2010 by Mark Murphy

I have an advantage over many coworkers, both male and female. The cube walls in my workplace reach about an inch above my shoulders. I don't think this is unusual as they are standard corporate cubicles. I can see over the walls of the maze, unlike the rest of the rats that are running around in the trenches. Sometimes I can see one pop it's head up over the wall to get it's bearings, but for the most part they follow familiar paths through the maze unable to see if it is the most efficient path to their destination.

Do you ever feel like you are running blind, following familiar paths, or following the crowd when making IT decisions? There is a whole maze of options: open source, PHP, Java, .NET, Unix, Linux, Windows, IBM, Microsoft, ... If you are in the Cincinnati, Ohio tri-state area, and want a boost over the wall, or want to talk to someone who can see over the walls of Information Technology, give Star Base a call.

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.

Everything Old Is New Again

Monday, March 8, 2010 by Matt Warman

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.

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?

What makes a good BA?

Friday, February 26, 2010 by Aaron Whittenberger

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

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

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

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

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

Stop Whining

Friday, January 29, 2010 by Matt Warman

I don't often get on my soapbox, but I feel it's time for this. Stop whining! This refers specifically to application development, but I guess it can be applied to most everything. The point I am talking about is application frameworks.
I am using JavaFX, which is relatively new. The problem it is trying to solve is to remove the cruft from desktop application development (Swing), add 2d animations, and be able to run on a variety of devices and platforms. For me the holy grail of Java development would be to create an application that runs on mobile, desktop, and browser, all using the same code! JavaFX does this nicely. Some application development people won't even look at it because features like menus are not there yet. Are there some things missing? Yes, but there is a difference between “where's function X?” and “Epic fail! I can't do anything because function X is missing!”.
All languages, especially new ones have holes in them. You must learn to work around things, that's why I call myself a hacker. Would I want to have something work out of the box? Of course I would, but I also understand that knowledge comes with getting your hands dirty. Just because I can't drag and drop a control doesn't mean it doesn't work. I think the rule of thumb for me is, if the work takes more code than the application I am working on, then's it's broken. I think the whining is more apparent in the younger guys, because of the great things we can do in our IDEs. Not to sound like a greybeard (but I will anyway) is that I started coding Java in NOTEPAD! The same is true with HTML and XML. I love that code completion and other useful features have become standard now, but I bring this point up for a reason. I know how to fix it when breaks, because I know how it's put together.
Sure code is tough, but if you think writing an application is tough, you should see what it takes to write an API. The application development “magic” doesn't write itself. If something doesn't work right, investigate it, instead of complaining. You may have the key fix to make it great. I know you will learn something during your research. You can't drag that control, so you will wait until it's so easy, even a caveman can do it. If you do, you may be replaced by a cheaper caveman.

Deploying JavaFX on Glassfish and Facebook

Thursday, January 21, 2010 by Matt Warman

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

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

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

Riding the Wave

Thursday, December 10, 2009 by Matt Warman

When I went to JavaOne this year, I had some friends who went to the Google I/O conference a few days before. Besides getting a new G2 phone (lucky), they were raving about Google Wave. Google recently released Wave into beta, and I have had a chance to play with it.
For those who do not know, Google Wave is a new type of communication software that allows real time collaboration. I know, it sounds all buzzwordy, but it is real cool. Think of Wave as email, SMS, and a working SharePoint all in one. To start a Wave you select new and a text area displays. Select from your contacts to add people, write some text and press send. Sounds like email right? Well, what if after some correspondence, you need to bring other people into the loop? And those late comers are now asking new questions? I don't know about you, but I get confused trying to read emails with lot's of history, and getting new emails based off of some of that history. Google Wave fixes this because everyone is updating a single thread in real time. If you are added late, there is a play button to show the order of the messages. Since it is in real time, all response are shown when entered. You could follow a meeting while listening to a conference call, and ask questions during the meeting, instead of having a second meeting to discuss the first meeting.
Collaboration is the key aspect of Wave. I am using Wave to let some people in Brazil help me test my JavaFX application. As a Cincinnati based application development person, this already saves me time and money. I added a zip file, and instructions on how to use it. I can get their feedback, and update the zip file. I think all application development people can see how useful this is. I can update my code to my users, and have a history of feedback. This will work well for those “confused” management types who “forgot” their feedback.

Google Wave is also a development platform. You can create your own widgets to run on Google Wave. The widgets provided by Google are a poll widget, collaborative Sudoku, and emoticons. I have used the poll widget, and works nicely. If you have a yes/no/maybe question to ask, it really is useful. I have an idea of using TTS to create “talking” Waves.

The one thing I would like to point out is that you will be able to run the Google Wave engine on your boxes. That means you can have a “private” Wave and a “public” Wave. You can set access restrictions on Wave, so you can have control of who uses Wave. Now that it is in beta, look for an invite and get riding!

IBM, Java, and the Community

Thursday, November 5, 2009 by Matt Warman

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

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

IT Outsourcing in for some big changes

Tuesday, October 6, 2009 by Aaron Whittenberger

A new report from Gartner Research Firm

IT Outsourcing is not going away anytime soon, but a new report from Gartner Research states that the market is in for some big changes. The report predicts that one in four business-process outsourcing firms will disappear within the next three years.

The article in InformationWeek gives advice to CIOs who wish to initiate a new IT Outsourcing contract on warning signs to look for in your prospective BPO partner that would indicate this firm may not be able to fulfill any new contract:

1.    Are they losing money?
2.    Are they winning new business?
3.    The loss of marquee clients.
4.    Poor capitalization is impeding growth.
5.    Toxic exposure to tainted financial firms.
6.    Lock down your exit strategies.

In another article in EconomicTimes I read that IBM will goble up half of India’s IT outsourcing business in 2010.

This is not to suggest that the offshore IT outsourcing business is coming home. IBM’s business is international. With IBM awarding one-half to 1 billion dollar contracts, many India firms will not be able to compete in delivering hardware, software, IT consulting services and integrated business solutions. IBM is one reason that 25% of IT BPO firms will meet their demise within the next three years.

Using Zembly

Wednesday, September 30, 2009 by Matt Warman

I am working in the Cincinnati office writing an application using Zembly. Zembly makes it easy to write applications because the authorization/infrastructre piece is handled for you. As any application development person will tell you, connecting to a new or different system can take up time needed for solving the problem. Especially for systems that you don't control. I always make sure I can connect to a system before even writing the application. Zembly takes care of this for you by using a keychain metaphor. For example, once you have set up development for your application. you can store your application public/private keys in the Zembly keychain. Your application development team can go through Zembly to connect directly to your application. Without Zembly, you have to lookup and pass session keys. While not difficult, finding the right calls isn't apparent. This is especially the case for Web Services. I can use Zembly to call Web Services from Flikr, Google, Amazon and others. Once I setup the keys, the authorization piece is abstracted leaving your application development team to solve the problem, and having time to add additional features. You can use the Zembly service by downloading the z4cl jars from Zembly, or using the integrated jars in NetBeans. Netbeans not only has the jars, but allows you to search for and filter Web Services. Once found, you can drag and drop the service into your application, and replace the default information as needed. Your application development team can be much more productive using Zembly, giving them time solve and enhance the problem at hand.