Building enterprise scale software solutions requires skills and experience beyond the scope of your senior programmer. You need someone with a vision, someone who can keep an eye on the big picture at all times, someone who can translate your business strategies into meaningful, cost effective software solutions. Whether it is designing an application framework or a deployment strategy, you want to work with a software architect who can efficiently formulate the right solution for your environment, and collaborate with both your business and technology people to lead the project to success. My background in systems administration and software development equips me with the right set of skills needed to fulfill these responsibilities.

Essentially, I think software design is similar to playing with Lego bricks. You are asked to build a Lego ship. You get a bucket of manufactured bricks. How you build the Lego ship is up to you: You can get creative, and use only a few pieces to assemble a figure that resembles a ship, and build a helicopter with the remaining pieces. Some would call that resourceful. Others may complain it does not follow standards. Or you could pull out the bundled instruction sheet, and follow the guidelines. Some would call that addressing the requirements. Others may say you are an evangelist.

Let’s face it. You need someone creative; otherwise, they wouldn’t have called it software “design”. You need someone who can communicate what they “design; whether it is UML diagrams, text documents, or verbal communication… being able to think is not enough when you are in a room full of people.

My skills and experience will add value to your team in areas including (but not limited to) software design, database design, test planning, installation and upgrade related concerns, and the appropriate documentation of respective topics.

Small and mid-sized businesses do not necessarily need or can afford to employ a fulltime business analyst. Therefore, consultants or software architects are traditionally expected to be armed with the skills of a business analyst.

Throughout my career, I’ve worked with seasoned analysts as well as half-baked programmer / analysts. I’ve collected and written requirements as well as reviewed them. I’ve written functional requirements, and use cases.

You should ask yourself if you really want to work with an analyst that thinks “add book” is a use case, or someone who captures the actual business need behind it that triggers the reaction of adding a book. An appropriate business analysis phase does not only increase the chance of success, but it also usually results in the optimization of the actual business process.

The “why-is-this-button-not-pink?” syndrome… In other words, you may have built the most sophisticated software system in history, but it means nothing to the users if they have to spend 15 minutes to find their way to that one button that performs the task that will allow them to “do their job.” Confusing artistic concerns with productivity hence the “real” user experience is a path that leads down that “pink-button” dilemma.

My approach to designing the appropriate user interface is to start with a solid set of software requirements and / or use cases as the guideline. Then start involving the “actual” users as early as possible in the modeling process. Building wire frame models or screen mock-ups does not and should not drive the development of your system. Your GUI should be a projection and presentation of “the services you provide.” A well documented GUI design should provide the developers with enough information to allow them to build the corresponding modules / screens.

The GUI design process should involve parties from both the graphic designers and the stakeholders. Let your Photoshop-strapped web designer design the user interface of your application, and get ready for a user experience nightmare.