Business Application Development

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:

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

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.

“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.

 

I read an interesting article in Agile Journal today titled "What is Best, Scrum or Kanban?" To a business application development specialist working with many application development teams, this is an interesting question. If you are in the same boat as I, maybe you already have a preference. Perhaps the article may sway your opinion.

If you are not familiar with one or both of these application development methodologies then the article will be very good reading for you. In a nutshell, both of these methodologies are used in the Agile application development style, as opposed to the SDLC or waterfall application development style.

In Scrum the project team decides on what deliverables it can deliver within one iteration of time. The team decides how long this time iteration is, usually two to three weeks. So Scrum focuses on splitting large tasks into its smallest pieces and delivering pieces of the project very quickly. This style tends to put the project team in sprint mode all the time.

Whereas, Kanban focuses more on steady workflow. The project team decides on the limit on the amount of work it is capable of accomplishing and sets up the workflow of tasks to ensure that the end result is accomplished. The article gives example of a Kanban chart and describes the similarities and differences of the two methodologies.

After reading the article and through my own experience, I would ask do these two application development methodologies have to be mutually exclusive. Can these two methods work in conjunction with each other within a project? Perhaps at the same time, or that you start with Scrum and move to something more along the lines of Kanban. Take this to the broader picture, do Agile and SDLC project methodologies have to be mutually exclusive? Can’t Scrum and time iterations be used within the SDLC project life cycle? What do you think?

1. Document more than the minimum 7,500 hours of business analysis work.  This ensures that if your hours are reduced in the review process that you will still have enough hours to qualify to sit for the exam.  This goes for total hours as well as hours in each of the knowledge areas.  I personally documented 9,000 hours on my application.
2. Put the language on your application in the wording of the BABOK®.  By putting your work tasks and deliverables in the language of the profession it is less likely that the hours will be discounted in review.
    

Business application development needs to accelerate faster.  Some are still talking about getting IT solutions to the web.  We should be talking about how to get IT business applications WAP enabled.  As voice and data networks continue to converge, consumers are going to want new and different way to access IT solutions.  Some have struggled with web application development and WAP is going to be a little trickier because the user interface is small and will probably need to be re-worked for the smaller display. 

In part-one I shared that on this trip, the coverage on my new phone was very acceptable.  In this post I will share some of the features I have used.  One of my requirements was to have a handset that supported navigation.  On the old phone I used Navigator that has a female voice, so I named her Suzy.  My new phone has Nokia maps and has a male voice, so I will call him Coleman.   Suzy has helped me many times and I have confidence in her, so it was up to Coleman to prove himself.  While we were still in the mountains of Maryland, I programmed the final destination into both phones.  It took a few minutes for the Nokia to find our location, but once it did, Coleman gave me turn by turn instructions, ETA and other things I expected.  Even though I had cell coverage, Suzy was not able to connect at all until we were out of the mountains.  I have had this problem before with Suzy before and it’s really quite annoying when you really need directions.  The conference is at National Harbor which is been open less than a year.  As we got close, I could see the Gaylord resort, but Coleman kept insisting we make a legal U turn.  Nokia downloads map data to the phone and navigator send information through a data network.  If there is no data network, no maps.   The downside of the Nokia is it takes up phone memory.  Right now I’m call this even.  There are pros and cons to both.

My new phone is a smart phone, so there are two other options that I am aware of.  Telenav is subscription service that is very similar to Navigator.  I can also download a Google maps application as well.

Another requirement that I have is my contacts and calendar be synced to our server.  The Nokia software does a great job at this.  Another option that I need is to be able to tether the phone to my notebook for broadband internet connectivity.  I have not been able to test this on my new phone yet.

One of the goals of the switch was to save some money.  Because our new phones are smart phones, they need full data service and so I’m ending up at about the same cost. So the bottom line is we ended up with more capabilities for the same price.  From what I see so far, integrating voice and data applications and having them work well together will be the next application development challenge.

The news this week is Oracle buying Sun. As a Java application development guy, this is very important news. I recently wrote about my feelings for an IBM merger, so this pairing is interesting. Larry Ellison had big praise for Solaris and Java, but nothing on MySQL. This is my take on the big points and questions I have.
Solaris
It is apparent that Oracle wants an OS to be a full service enterprise application development provider. They want to compete against Microsoft and IBM. I don’t see Oracle doing anything to hurt Solaris. I think Oracle can do a better job than Sun in this regard, as long as they use Sun’s customer service model.
Java
Oracle is a big Java user. The question for me is will Oracle "IBMify" Java? Creating proprietary hooks where none is needed to make a profit is dead wrong. Java is the dominate language, but other languages were dominate in the past. If Oracle can resist the temptation and just be the caretaker, java application development will be dominant for some time. If not, Java is open source, which means a "free" Java will be around, but multiple, incompatible versions of Java will kill it. I see Scala as a viable successor to Java, so I think the fragmentation issue will disrupt application development, but not move everything to .Net.
NetBeans
The fate of my favorite IDE is in much better hands with Oracle than IBM. NetBeans is a big part of Sun’s offerings, so I don’t think there is an issue.
MySQL
Many people lament that Oracle has MySQL finally. There is some well founded concern, but I see Oracle using MySQL as an entry into smaller markets. If you can brand MYSQL as Oracle’s "lite" database, then small businesses can use MySQL, and then seamlessly move to Oracle when the business grows.
Questions
What about JavaFX? This is the first step to the great convergence of write one set of code to run on mobile desktop and web. How much autonomy will Sun staff have? What about Glassfish? Only time will tell.

If you are long term Java application development person, you are probably familiar with Enterprise Java Bean (EJB) 2.0 . They have been notoriously difficult to use, so the popularity of Object relational mapping tools like hibernate became the standard use for enterprise application development. Sun had JDO, but it was little improvement. The key functionality of Hibernate was the use of Plain Old Java Objects (POJO) to handle the heavy lifting. The big issue with hibernate was that it was resource intensive, which left non-enterprise projects without this useful technology.
Sun worked with the ORM teams and the community to create Java Persistence Objects (JPA) to replace EJB, and to create single standard technology. The big advantage of JPA is application development teams can use it for both EE and SE projects. I have many database driven projects written in Swing. It is time consuming and boring to write boiler plate code to handle moving data to/from the database. JPA removes the plumbing part of my project, so I can focus on problem to solve. My IDE of choice is NetBeans, and has complete integration with JPA, so I can use tools to make my basic connections. Typically in Swing I would create a POJO that represents a row in the JTable. I would then create a custom table model object that uses an array list of row objects to populate the table. I wrote a method that reads from the database, creates rows objects, store the row objects in an array list, move the array list to model, and set the model to the table. With JPA and NetBeans I can bind the JTable to a database table, select which fields to display, and JPA entity classes are created for me. I just save 1 – 4 hours of design and implementation time! JPA uses annotations to specify the database, table and relationships (if connecting to multiple tables). I have a single object to do all of my connection, display, and CRUD functions. JPA uses Oracles toplink to help with the heavy lifting. For those of you application development guys who like to do it yourself, there are tutorials on the sun site.
The best part is that JPA is used in my JSF projects, so I use the same patterns for web application development and desktop application development. There is a learning curve, and Java 6 is needed, but it is well worth you time to learn JPA!

As an enterprise application development team member, I have had a long history with both companies. I started in this business with IBM’s CICS and COBOL. Publishing one update every 10 years or so, COBOL could not compete with the newer languages of the time (Java). IBM only started looking at viable additions or enhancements after losing lots of business. Having seen what IBM did with their languages, the outlook is not so rosy with Java. I also came from a vendor (Silverstream), which took Java and created proprietary extensions. When Silverstream got bought out by Novell and disappeared, my focus was to convince employers that I did in fact know Java. Since then, I have had a personal dislike for non-standard "enhancements" to technology. IBM’s WebSphere falls directly into that category. Taking a perfectly usable Apache web container and adding "enhancements" so it doesn’t follow apache documentation, but needs IBM support makes me angry. Their JDK implementation leaves many things to be desired. IBM has a history of taking open source technologies and contorting them so only IBM trained personnel can use them. To most application development team guys, IBM is a huge thorn in their sides. It is management not IT that purchases big blue.
It’s not just Java, but many of my other favorite technologies that IBM may toss. Glassfish is a free, easy to use application server that uses the latest EE5 code base. WebSphere 7.0 has been recently released to use IBM’s EE5 edition. 2 years after Glassfish! I am a long time MySQL user, I don’t ever want to use DB2. I can’t imagine using DB2 for my passion projects. NetBeans has made great strides in the IDE space, and is becoming the choice of many application development team members. Whether you use all IBM or all Sun is moot; we have choice and competition, but not for long.

IBM’s lack of focus on marketing and developer mind share (anyone remember OS/2?) are important reasons why I hope this doesn’t happen. In a perfect world, Google would swoop in and buy them. Their cultures are very similar (many former Sun people work at Google), and the competition would still be there.
Yes, many of these technologies are open source. They will not just disapear; but without corporate backing, they will not see light of day in the corporate space. The reason Red Hat and SUSE are major Linux distributions is that Enterprises can have Service contracts. If IBM chooses to abandon them, I don't see widespread use, unless the technology is overwhelmingly compelling.

Organizations that build strong value-driven cultures frequently achieve high performance.  The values that are developed must touch every department in the organization or the overall operation will fall short of its targeted goals.

As an IT consulting firm in Cincinnati, we see many different approaches from many different companies and it is the “out-of-the-box thinkers that seem to continually apply lateral thought process on a continual basis and always stay a few steps ahead of their competition.

One would think that IT departments would observe and learn from this but way too often they do not pay attention to the business drivers of the organization and continue to stay with the same IT infrastructure year in and year out and resist change on any level.

There are those that would argue that “if it isn’t broke don’t fix it” and I agree to a point but I believe that if IT professionals are going to contribute to building a strong value-driven culture that works to achieve the business goals of the organization they are going to have to look at new approaches that may enhance the very work they are held accountable for.

Being responsible for business development for our Cincinnati IT consulting firm, over the past couple of weeks I have approached several clients and potential clients with some new value propositions.  Many do not want to talk about them, nor are some even curious on what they are.  Everyone has a full plate and little capacity for a new application development services, IT training or IT consulting project.

However, here is a question that I have for these individuals.  If it is true that information technology changes every fifteen to eighteen months, how can the IT systems and enterprise IT applications that you have had in place for the last three to five years continue to be relevant or simply as efficient as they could be?  Do you not owe it to yourself to at least listen to what an IT consulting firm here in Cincinnati has to offer?  Perhaps that IT consultant has significant experience with a solution that can make a difference but you are unaware of it because you are resistant to change and everything is running 'smoothly'.  I can understand your hesitation but what if the new solution could greatly improve your IT infrastructure, decrease costs, fuel improved productivity or more effectively balance your IT staffing needs?   Wouldn’t it behoove you to at least listen?
 

One of my favorite movies of all time is Cool Hand Luke starring Paul Newman.  That movie has a famous line issued by the prison captain.  After trying several times to get Newman to conform to the prison life style that captain turns to his surrounding audience and utters the words to his surrounding audience; “What we have here is a failure to communicate.”

I have used these words with my own children many times but I wish I could use those words with clients when within the business technology consulting space.  Far too many times projects do not go as planned and it usually is because of a lack of communication.  That is why in any IT application development project it is imperative that each business unit that has a vested interest in a given project makes it clear exactly what they expect and what is needed.

Experience has taught me that merely stating what you need and what is expected is not enough, especially in the area of enterprise application development.  Each party or business unit needs an internal champion for its cause.  As any given project progress each business unit needs to make sure there is are checks and balances against their wants and needs list to determine how many of their stated needs are being met.  If they are not being met the project needs to stop temporarily until everyone that is involved with the project understand that needs and expectations are not being met and the team collectively need to make a decision on how and when to move forward.

They IT projects fail because there is a lack of planning, a lack of level-setting expectations and an overall lack of communication.  Must organizations understand this but more times than not they do not learn from past experience and move forward without consensus.  They are well into the user acceptance stage with the built in functionality asked for but for some reason the final approver says this is not what I asked for.

So what goes wrong with the 80% project failures, and what can we learn from this?  Several things occur on many levels! 

Let me list some of the reasons for project failure and actions that need to be taken
.

• Consensus was not attained – it is apparent in most failed IT project that the approver and the business unit leaders have different, and at time conflicting, goals for the project.  Make sure there is “buy-in” along the path of development by everyone involved.
• Expectations are not managed – the approver wants one thing and the developers built something else base on the feedback of various business units.  Make sure you manage everyone’s expectations throughout the lifetime of the project
• Usually the final decision maker is excluded in most of the development meetings.  This is a very bad practice.  This responsible executive must be in on all major decision so there is no pushback at the end.

The lessons here are clear.  Identify the stake holders, come up with a communications plan, implement the plan and make sure there is communication and cooperation from each vested participant to ensure that your project does not fail.
 

Wednesday I wrote a blog on the new role of IT Today.  Ironically I was reading a blog on CIO magazine today and read an article by Thomas Wailgum on Why_the_recession_is_marginalizing_CIOs.  Thomas took a different path than I chose in my blog but the message remain the same, CIOs and IT personnel must continue to make themselves relevant or they will risk becoming a victim of knee jerk reaction from organizations looking to down size in this downturn economy.

I have written before that any one in the information technology world must come to gripes with the fact that upper manage and business as a whole does not understand the technical world not do they try to.  For so long information and IT related work tasks were simply thrown over the wall and it has up to the IT director to make some sense of it and to make sure that everyone was taken care of throughout the enterprise.

Well, the new edict if focused on strategic alignment of the enterprise and business processes and methodologies and how they relate to the over all mission of the organization.

Business application development must focus on the business and not the technology.  IT directors and application development specialist must understand that they must use technology to assist their organization to reach their goals and objectives in a quick efficient manner.  To not do so makes you vulnerable and expendable. Be proactive instead of reactive and you will make yourself more valuable and more relevant to your organization.  Everyone is being asked to do more with less and IT departments and the personnel that work within an IT department are no different.

Develop the attitude that you must continually push your capabilities and ability to think outside of the box through the creation of new process and methodologies to enable your organization to gain a competitive advantage.

Remember, think business first, technology second and ways that technology can empower your organization to continually reach their business goals and objective.  More important you will continue to be relevant and valuable to your organization and will not have to concern yourself with down sizing and having the rest of the organization minimizing the role of the CIO.
 

Enterprises will soon recognize that IT is an organizational asset, not simply an organizational structure. Senior leadership will embrace that their understanding of IT and the ability to apply this knowledge in imagining future possibilities is essential to extracting greater value from IT-enabled initiatives.  In addition, there will be broad-based acceptance that day-to-day business operations are dependent on IT and that the costs and risks are too high to continue to place the burden of responsibility solely on the CIO and the IT team.

I believe IT will transition from being the sole provider of the asset to enabling the IT capabilities of others in the enterprise.  Application development projects will no longer be centrally controlled but will be part of an entire enterprise-wide solution.  IT department will become enablers not the central focal point of technology.  Information technology consulting services will need to meet the needs of the entire organization not simply the IT department.  The dedicated IT staff of the past will need to ensure that information technology is applied in direct support of the business strategy to help the business to compete and grow while outperforming their competition.

IT business solutions will shift from servicing to coaching on the proper solutions based upon the company need.  IT departments will grow into corporate leaders instead of trying to be the one stop shop for all technology products and services.  Leaders from each department will be accountable for their own needs.  They will be accountable for meeting the needs of the business and that includes technology.  Once business leaders achieve their goals by increasing their knowledge of systems, business processes, and information and how to identify justify and execute IT-enabled change, organizations will operate as a truly integrated enterprise instead of a company of soloed departments.  Once this type of approach is embrace, communication will improve, measurable progress will be seen and a true integrated enterprise will be realized.  

As an enterprise application development team member, I do a lot of interesting, low level things. My client has an application that needs a huge heap for their Java application (1.5 GB and needs more).For you non-Java folk, a heap is a contiguous blob of physical memory. I know really that an application redesign is needed, but the business unit wants more products on this application. With growing business and shrinking heap size I am looking for short term fixes to gives time to develop a long term fix. We are currently on a 64 bit OS, but we are using a 32 bit application server and JDK. The upper bound for a 32 bit heap is 4GB. Given where we are, and that we can move to 64 bit architecture, most application development team members would just go for it. On the surface, 64 bit sounds like double the space. It is true that 64 bit systems have double the address space, but that also has about 5 times the registers (224 versus 24). That is a lot of space but that is also a lot of overhead. By moving to a 64 bit system, we will see a 71% performance drop. That means that in order to have the same operation level, we will need nearly a 4GB heap to match a 2G heap on our 32 bit system!

There is good news however; the theoretical memory limit on a 64 bit system is 1Exabyte! The order of magnitude goes Gigabyte, Terabyte, Petabyte, and Exabyte. Someone calculated that it would cost 2 trillion dollars to purchase that much memory. Well, we don’t need that much memory, but moving to 8GB of memory for 4GB of performance isn’t a great short term fix either. Sun has realized this, and has created a JVM compression switch that allows it to run at 95% of the performance with only a 3% memory footprint growth. That means we can use an 8 GB heap and will perform as expected on a similar 32 bit system. The problem is that we are on Java 1.4.2, which means that we may run into deprecation issues. It would also require us to move to the latest version of our application server, which could bring its own share of issues.

Our plan is to move in stages, after thorough testing. Sometimes bigger is not better, at least until you understand it better.

A few weeks ago I met with a client that was looking for some business analysts to help them with business application development.  One of our Cincinnati IT consultants just got his CBAP and he was going to be available in the right time frame, so I started to think this would be a perfect fit.  While there are thousands of business analysts around, there are less than 500 CBAPs in the world and we are fortunate enough to have one on our IT staff.

This IT staffing position should be a slam-dunk, right?  Wrong!  The client also wanted very specific industry experience.   While our consultant has industry experience, it was not in the right area.   Fortunately we were able to recruit business analysts with the needed skills.   As Michael points out as part of this post, “clients are very specific on what they need and they are unwilling to pay for “learning curves.”   Pretty much seems like we have become a “risk adverse” society.

Part one discussed security. Part two discussed standardization. Part 3 will discuss specialization, and solutions to the problems.

Many large organizations compartmentalize into smaller teams to take care of specialized tasks like operating systems, networking, or application development. Specialization works best on a smaller scale, where networking people can focus on infrastructure and application development teams can focus on business support. This specialization model breaks down when you apply it to individual technologies like application servers. A specialized group performs their tasks for the entire organization. Basically, they are treated as a vendor. Job orders come in, and they fill it. Enterprise application development teams routinely use and administer application servers in their job. Moving administration tasks to a specialized group is unnecessary. Although application servers needs specialized knowledge, business rules and third party tools affect how the application servers are used. People who have only the technical expertise but not the business expertise can’t quickly diagnose a problem, and productivity slips.

Are there any solutions to the problems?
Give time to application development teams so they can try new approaches to existing business issues. Google gives their employees up to 20% of their time to work on passion projects. If you can allow your application development teams to do research and to work on improving the process, your application development teams will learn valuable new skills, and the enterprise will get streamlined processes.
Give application development teams their own area to develop new ideas. Let your application development teams drive standardization, not management. Your teams are much closer to the technology. The research would done in area that is isolated, so security is less of an issue. If issues arise and your application development team can’t solve it, just reset the area.

Setup a form that answers the basic questions like "what process does this improve", and "how much improvement". By creating a standardized form, you can remove most of the political motivations (Microsoft vs. Linux for example), so you will get better results. Create a standardization board that can vet the new technology, and determine if it can be used in the enterprise. Make sure that security and IT management are a part of this process.

If you are going to have specialized tech teams, assign one at the beginning of the project. Documentation and business issues can be utilized so your specialized application development team members can be put back into the pool, and another can quickly come up to speed in an emergency. Treating each application team members like a vendor removes cohesion and vital communication.

The common threads throughout these posts are communication and trust. Communicate to your application team members that new ideas are always welcome, and if not implemented, there is a valid business reason. Trust your application teams to do their job, and handle the few who may break your trust.

 Recently I read a blog posting by Christopher  Dawson titled “Where are all the programmers?”  The article talks about how this individual attended a job fair in Boston targeted to recruit IT help by various organizations.   You can access his blog at:

http://education.zdnet.com/?p=189&tag=nl.e623.

Christopher made an observation that those of us that are involved in Information Technology Consulting and IT recruiting already know.  The majority of the candidates that organizations have to choose from are foreign nationals coming from India or the Soviet Union.  Companies looking to hire part time contractors are sometimes taken back because they do not realize that there are not many domestic application developers to choose from in a small geographic area.

I see a couple of contributing factors to this occurrence.  In an area like the Greater Cincinnati area we find developers with a specific skill-set and many times these individuals have not upgraded their skill-sets for quite awhile.  Potential clients are very specific on what they need and they are unwilling to pay for “learning curves.”  Clients seek out individuals with multiple skill-sets that can multi-task, change and adapt as technology or market needs dictate.

The next area of difference I have observed is that foreign nationals seem to have made a commitment to life-long learning.  They understand that to make themselves employable they need to have multiple skill-sets to make them selves employable.  American workers want to focus on a couple of skill-sets and then become upset when they cannot find employment.

The needs of the world have changed and the needs of enterprise application development have changed as well.  Organizations need a variety of skill-sets with any person they hire either on a temporary or permanent placement.  If I review twenty five resumes for an ASP.Net person with experience in Java and SQL, twenty two of those resumes will be foreign nationals, mostly from India.

Why is this? I believe the foreign nationals are hungry and realize the opportunities that this country can bring to them so they are driven to succeed.  Meanwhile, American developers seem to be content with skill-sets they learned over the past ten years and do little to improve themselves.  Last week I spoke with a potential candidate that was down right angry at the suggestion that he work at increasing his skill-set.

Technology is a lifeline for any organization and the needs of these organizations change on a constant basis.  These organizations need good IT talent to support their systems in a variety of ways.  They will go where they need to and hire who gives them the best competitive advantage within their given market place.  That means the professional developers that they hire must have multiple skills.  It seems to me that is an American application developer, business analyst or systems analysts grasps these concepts they can compete as long as they are willing to continually upgrade their skill-sets and not lose positions to the foreign competition.

The main point of my blog is to discuss the best way to handle application development. As a long time enterprise application development team member, I have seen the right way and wrong way to things, and my blog (and many others) will try to tell you "the right way" to do things. Nobody, until now, will discuss handling "the wrong way" to do things.

Background
My client purchased a product from a third-party vendor that seemed to have all of the features they needed. The only problem was the product is really meant for small/mid-sized businesses (SMB), and not for the company of this size. This product just doesn’t scale well, and since it’s a vendor product, I can’t do anything directly to fix it. We have issues with the current build, but the business unit wants to increase their presence in their current product, and roll out a new product by year-end. Either project would ambitious given our current state of production, but the relationship between the business unit and IT is one of a customer/vendor. There is nothing IT can say to focus on only one project. What is a consultant to do?

I have three things you should try to do focus on in such a situation:

Keep your head – There is a saying, "If you keep your head when everyone is losing theirs, you will have one more head than everyone else". This means to get the most out of you, the product, and the project, focus on the flaws that can be fixed. Many of your client’s staff is directly responsible, so they tend to vent more. They are focused (and rightly so) on the problems giving them headaches. Look beyond the problems, and try to find a work around. Suggesting that the vendor re-architect their product may be the obvious answer, but it will accomplish nothing.

Make suggestions, respectfully – Clients who have been dealing with an issue tend to get cranky, and it shows with correspondence with vendors. Often times your counterpart has the same limited amount of change as you, so keep that in mind. Keep opinions, comments, and other issues out of your communications. Just explain your situation. If you have a better way of doing something, send an example. The extra work will help in your relationship with the vendor, and will help with fixing the issue.

Don’t worry about your duties – The product is Java based, and so the application will stop running because it uses too much memory. It will take a snap shot of the objects used, which is called a heap dump. My job as an enterprise development architect is to do what I can to get things running smoothly, so I have been analyzing the heap dumps, researching alternate paths for their current architecture, and suggesting possible solutions. Since they are a vendor, I have no access to their code, but I can see how they doing things by the heap dumps. Sometimes you feel like your client is the vendor not the client, but these experiences are valuable for your next assignment.

In summary, you are in a tough situation, but hey you’re an enterprise application development consultant. Stay calm, analyze the situation, make suggestions where appropriate, and do what the job takes to make bad situation better.