Category: Consulting


Are most Information Technology Architects more Managers or Technologists? Is the 50/50 balance really possible?

Filed under: Consulting, Emotional Intelligence, Enterprise Architecture — Leave a comment
November 15, 2009

IT Architecture is the evolution of a career, in that it takes years of experience designing, building, and rolling out systems that match a set of criteria.   The hardest part as I have detailed in previous posts is not the technology however, but matching the technology to the requirements.   Knowing which questions to ask at the right time, so that you can flush out more from your clients and customers than just a set of screen shots, or a bullet point list of hardware requirements.  The Architect must take a broader outlook then this, always having in the back of their mind what other factors could be impacting the solution, or strategy that have not been communicated.

I recently posted this question on LinkedIn and got a few key responses I wanted to highlight here.

IT architects are visionaries, coaches, team leaders, business-to-technical liaisons, computer scientists, and industry experts. – OpenGroup.com

I believe that a crucial role of a Solution Architect is to act as the link between business stakeholders and technology experts. You need to exchange ideas effectively with both groups and need significant technical and business understanding for this to be possible, without necessariy being an expert in either area yourself. Typically, architects come from a business background and acquire technical knowledge or come from a techincal background and acquire business understanding. In my experience, the latter case is more common and architects are therefore more likely to lean to the technical.  – Paul Harris – CRM and Integration Consultant

In short, the Architect is the only guy in the room who has decent street cred with the Development and Marketing folks. He’s diplomatic and savvy when it matters, and can think very critically about architecture and applying technology where it counts.  AD Kent – Managing Partner at DocuConsulting

As all three quotes explain, the Architect is the link between business and technology, which means that he or she has to be able to communicate and build relationships with both sides.   For instance, if the Architect is in a meeting with the CFO of an organization, project and operational cost are important. It is important to communicate how the given project or strategy will cut costs to the organization.  If you don’t know hard numbers, be prepared to at least communicate in terms of hours spent in the current environment to generate output, and how a new architecture, system, or solution, will cut that down over time.   Many CFO’s can calculate simple math in their head, and when they hear “reduction in hours to produce” they know your talking in terms of savings to the company.    The better your statistics are, the more inclined they are to support your initiative.

This conversation is completely different than the one you would have with engineers and developers.  When communicating with these folks, you must similarly direct your conversation to something that matters to them.  Performance, Design, Quality, Extensibility, Importance to the organization, are all characteristics of an Architectural knowledge base.   It’s also important as the Open Group states, to coach, mentor, and encourage your teams as part of the production endeavor.

So in short, the answer to the overriding question is yes.  The Architect must be someone who can operate with many different hats and gain the respect of peers, those reporting to them, management, and even sales and marketing.   This is often a result of many years of experience in all facets of business technology, and a general understanding of what each component of the business requires to be successful.

Tags:
Comment

Turning a Frustrated Customer into a Reference

Filed under: Consulting, Emotional Intelligence — Leave a comment
October 27, 2009

Have you ever walked into a new customer and realized immediately that they don’t like you?  Not you personally, but your company in general .

If you’re an consultant for a software company this is an all to common occurrence.    You see, before most customers are given the opportunity to speak with you, they have been through experiences with other members of your company.   Sometimes those are pleasant,  but sometimes –  They have dealt with Sales guys who have promised them the world, but have not delivered.  They have dealt with Support managers who have spoken pleasantly with them and said they “understand” but have not been given the power to pressure PD to fix their issues.   They might even have dealt with Product Development engineers who responded with the most horrible of quotations, “well why do you want to do that?”

After years of dealing with this situation, I have developed an approach and a philosophy that  I use to turn these customers into our biggest fans!

  1. The Customer is always right.   This is very cliché, and probably over used.  However this doesn’t mean that when you believe the client is making a mistake in their approach to a problem you shouldn’t speak up.  What it means is that ultimately they own the solution.  They support it long term, and it is their issues that you are trying to solve.   At the end of the day, they have the final say.   I like to present possible solution scenarios to the client, arguing the positive and negative to each approach, and then let them make the final decision.
  2. Never promise anything you can’t deliver.   Don’t tell the customer that you will get PD to fix a problem if you can’t.  This will just lead to more frustration by the client, and put you on their ‘unhappy with’ list.
  3. Understand and hear their frustration.   Most customers just want a sympathetic ear.    They want to know someone is listening to them, and that their frustrations are validated.
  4. Workaround Workaround Workaround.   Your getting paid to come up with solutions.   Sometimes these solutions are not the way “things should work” but are a stop gap until a better solution can be provided.   Customers will respect your ability to  come up with ideas to handle the given situation.
  5. Always have a list of their problems with you.  I like to keep a notebook with issues my customers have run across.    I will pull this notebook out from time to time and think about a good solid solution that may be provided.  This also keeps this customer fresh in my mind, and helps me bring up ideas when in general discussions with other members of my company.
  6. Success – This is the most important way to turn a frustrated customer into a reference.    Every successful project you are able to complete with a client, will make them bigger and bigger fans of your company.  Sometimes this means doing whatever it takes to make the project work.  Sometimes you will act as PM, sometimes an architect, sometimes a troubleshooter, sometimes a developer.   Successful projects lead to opportunities, and opportunities lead towards reoccurring revenue.
  7. Connect with your customer on a personal level.   Remember your client had hired you to be apart of their team.   While you might always be somewhat of an outsider, your skill set is why they have agreed to have you “point them in the right direction”.    So relax, your customer wants to like you… let them.

 

Tags:
Comment

Why are customers choosing SOA solutions?

Filed under: Consulting, Enterprise Architecture — Leave a comment
September 9, 2009

Increasing System Integration – Being a standardized method for communication allows multiple systems to interact with one another across the enterprise.

Increased Vendor Neutrality – the ability to use the proper technology at the appropriate time. Vendor neutrality within large organizations is important, in that it allows for the diversity that inherently exists within a corporation without limiting each part of the organization to it’s individual silo’s.

Enterprise Architecture – When you open up your application to other parts of the enterprise as a consumable service – or group of services, it makes the solution available to Enterprise Business Modeling and available as an entity that can be made part of a bigger problem solution. In other words, it gives the Enterprise Architects the ability to use individual solution architectures more as if they were components of a larger model, rather than as a self contained entities.

Reuse – As with the main driving force behind Object Oriented Programming, the ability to reuse logic is a compelling concept. If you build the same component each time you build a new system you in essence have to fund it’s construction each time.

Agility – The ability to use, then reuse – in different ways or for different requirements – system components as the business changes makes SOA extremely flexible to changing business dynamics.

Tags:
Comment

How do you know you’re developing what your customers want?

Filed under: Consulting, Emotional Intelligence — Leave a comment
August 11, 2009

I spent an hour last week talking to a couple of developers who are the main people behind a particular product.  I won’t name the product or the company, but let’s just say I have been personally working with this product on site with many different clients for the better part of 8 years.  The question I asked them is this..  “How do you know your developing what your customers want?”

Before I get to their response, let me say this.  I kind of set them up.  So let me give you a bit of background.   The product in question is being rewritten from the ground up.   So the architecture is changing.  But the architecture it self is not really of concern to me.   If they decide to use the MVC pattern with ADF that means as much to me as if they decided to build JSPs on top of hibernate objects using Axis to expose some web services.   What I care about is what happens when I take that product on site and have to make it work in front of the customers.

First of all let me say, I love working with customers.  I love the stress and the invigorating feeling of getting a idea to work, while the customer is breathing over my neck asking me when it’s going to be ready.  I don’t know, maybe I am an adrenaline junky, or maybe I just like to make people happy when they see the product working with their data.   But this part of my job is my most favorite.

With that said, I like to keep the happiness going.   I want to know that the idea I had to solve their business problem using the software they bought, is not only going to work, but is also going to make them happy long term.  I don’t want them turning around next week, and telling other people within their organization how disappointed they are.

So my focus has always been on the end game, and this always leads me to have the following questions floating around in my head.   What will happen when I leave this customer and they are no longer are paying consulting fees.  Will they be able to handle support for the installed solution?   Will they be frustrated by the software?    Do they feel as if their user base will appreciate how the solution improves their job?     In order to satisfy my questions I tend to spend a lot of time talking with the customer beyond what is required of me.

Other than the typical requirements gathering process, some of the questions that I like to pose to my customers when I am working with them.

  • What is the most frustrating part of this implementation?
  • What is the one feature you wish we could have that would make your job easier?
  • Tell me what are your users like?  (this one leads to really interesting thoughts.)  I typically follow up with what are their daily jobs like?
  • What complaints have you gotten from your user base so far during testing? (the responses here are also very different – a new blog posting someday)

So back to my original question.   The answer I got, did not surprise me.  It was a simple “I don’t know.”    Most development shops depend on a few people to tell them what the customers want.  And they code to those requirements.    This is the less costly, easiest way to go about performing development.. so it has it’s advantages.   However I don’t think it works well, and the answer to my question proved it.

This has to change.

Tags:
Comment

More On Agile – The Car Again?

Filed under: Consulting, Project Management — Leave a comment
July 18, 2009

The analogy I tried hard to make in my last few posts was to dispel the notion that software development is NOT like building a Car, or a bridge, or even a home. So let us as engineers and developers, move beyond that concept and begin to think of our discipline as more fluid.  I know many in my field will not like this, especially on the east coast, but my ultimate goal is to think of us more as a combination of surfers, artists, psychologists, architects, and construction workers more so than engineers.

To summarize the problems we face with the current methods in the world of software development;

  • Businesses Change – Let’s face it, we have all come to the conclusion in the last year or so that markets don’t always go up.  They fluctuate and sometimes unfortunately they crash.   Likewise Businesses are not always successful and if they are too inflexible to the market they will fail.   To counteract this a good business is agile enough to handle the changing market conditions.   With change, comes different sets of requirements, which current development methods do not handle well.
  • Communication Is Vital – In today’s world as illustrated, though with a bit of humor, in the British Comedy “IT Crowd” software development teams, and IT persons, are often very far removed from the business.   This makes it very difficult to communicate to those developing the software what the requirements are, as well as help those in the business understand some of the hurdles in delivering a particular requirement.
  • Motivation – This is a tricky one.  But let’s be honest with ourselves for a moment.   Many people in general work better and are more focused with deadlines.  Some people don’t always need a deadline, but it is safe to say a majority of people do.
  • Inability to measure progress – In today’s world progress is measured by something called a project plan.   A project plan is a nice little graph with tasks, and bars that show percent complete.   The percent complete is usually just an estimate given to the project manager from the developer.  In most situations, the Project Manager doesn’t have any idea what criteria the developer is using for the estimate given, but simply accepts what he or she is told.

Take a look at the Principles behind the Agile Manifesto and you can see how this method for software development addresses these problems directly.

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Directly each one of these statements of commitment deals with the problems in the current process, with the ultimate goal of a happier more satisfied user base.   With all of that said however, I will admit that while this methodology has a lot of appeal to the software development community when discussing this with the money people there is some difficulty.

Mostly because the Agile method never portends to cut the development cost.   By letting the scope of the project change over time, costs of development “might” in fact go up.  I say “might” because there has been many projects that I have seen that are amazingly under estimated who end up having major overruns, and high costs of completion.

So one must weigh the cost of getting something “done” versus getting something “right” in making the ultimate choice.

It is my feeling, and the view of the Agile camp that this choice is obvious.

Tags:
Comment

Hello World!

Filed under: Consulting, Emotional Intelligence, Enterprise Architecture, Programming, Project Management, Random Work Day Thoughts — 1 Comment
June 16, 2009

Hey everyone, this is my first Blog.  I have been a twitter fanatic for about a year now, and a facebook poster for well 2 years.   This is my first attempt to branch beyond that more personal social interaction and setup something a bit more about my professional life.   While there are many blogs out there, detailing all things Java, J2EE, Oracle and the like, there will be, and I promise this, nothing with the unique humor and outlook that I bring to the  table.

We are all unique right..  well I am a unique Geek.  I don’t really fit into your typical stereotype of your total geek, but yet I don’t fit totally into your image of a business guy either.  I straddle these two areas in my day to day life, and it’s my humor and my outlook that keeps me sane.

So as I increase my readership, I hope to learn from, as well as teach those who feel as if the world is an interesting and fascinating place, and that to operate in both the business and technical circles equally and with success, is an enjoyable experience.

Tags:
Comment
Follow

Get every new post delivered to your Inbox.