BA: Business Alignment

Wednesday, August 25, 2010 by Aaron Whittenberger
STAR BASE Consulting is conducting a new pulse survey this month asking the question “is there really a rivalry between IT and Business or is this all just sensationalized hype?”  I am very interested in seeing the results of this survey, but I believe I can predict the results.  In almost every organization I have ever worked in the “Us vs. Them” culture existed.  The relationship between IT and Business was more segregated, even adversarial at times, than that of a partnership.

Kupe tackles this topic this week on BA Times, where he discusses creating an environment in which the business wants to work with IT to derive technology-driven solutions.  Doug Goldberg does an in-depth analysis of the subject on his blog, in which he describes approaches that a business-side analyst and an IT-side analyst to take to create a collaborative environment.

This topic is nothing new, just as the relationship between IT and Business is nothing new.  It took decades to get it where it is today.  I am sure you can find bright spots in which IT and Business work together to achieve their goals, but in more organizations than not, this is not the case.  Just as business processes and technology advance year by year, the relationship between IT and Business can be made better.  I believe the Business Analyst is in prime position to turn the relationship around to a positive, collaborative, trusting relationship in which the two work together to achieve the strategic goals and initiatives of the organization.  Why the BA?  The BA is one role that works on both sides of the fence.  The BA works with business stakeholders to bring out requirements for business improvement or application development solutions.  The BA also works with the IT Solution Delivery Team to develop the solution that meets the business requirements.  As the BA works with both teams, they are in prime position to bridge the gap between the two.  So how should the BA go about bridging the gap?

Build a Relationship of Trust

One of the often overlooked roles of the Business Analyst is that of liaison between IT and the Business.  In order to fulfill this role the BA must have a relationship with both sides of the organization.  That relationship has to be built on trust.  The business must understand that the BA is there not only to gather requirements but to understand the needs of the business and represent those needs to the IT delivery team.  The IT delivery team must feel that the BA will represent the capabilities and limitations of technology to the business. 

Communicate

The greatest factor that creates the “Us vs. Them” relationship is a lack of understanding.  The business wonders why it takes IT so long to make a seemingly easy change.  The IT application development team feels that business can not communicate effectively and does not understand the process of making application enhancements.  Last month I spoke about creating a shared vision in relation to requirements and IT solutions.  The BA should also create a shared vision of the needs and limitations of one organization to the other.  The BA can communicate not only the requirements for IT solutions, but the stakeholder concerns surrounding those requirements.  This adds context and can improve the ultimate solution developed as it increases the IT delivery team’s understanding.   The BA can communicate to the business that the process of making application enhancements is more involved then changing a little piece of code and there it is.  Testing, Quality Assurance, moving changes to production, Sox regulations, post-install processes and support are all time consuming tasks and increase the amount of time it takes the IT application development team to make an application enhancement.  The more the business understands about these processes and the value they add to the solution, the more considerate they will be to the needs of the IT delivery team.

Build the Bridge

Through effective communication of the needs and limitations of one side of the business to the other and representing the other team to each team the BA can build a bridge of understanding between the two groups.  By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.

So take the liaison role of the BA seriously and work to replace the adversarial relationship with a collaborative, understanding relationship.  In this way you can show the BA value to the organization.

Why? Because that’s The Way It Is!

Friday, July 30, 2010 by Matt Warman

If you thought your job as an application development person is difficult, try being a consultant. I love my job as a consultant because I am able to affect change, that is, when people want it. The most dreaded phrase a consultant can hear is “that’s the way it is”. Those words have no rebuttal, no further review. It’s the organization’s way of saying “talk to the hand”! My job is to find gaps in code or process and bring them up to the client. Often times the client has fallen into way of doing things that are counter productive, or more likely, have not changed since the process was in place. A case in point, I was having a discussion with an architect about code review. I noticed that they had the Legacy style user, date, and change comments at the top of their classes. I made a review comment that they weren’t necessary, because Subversion tracks the changes for them. It was due to their work process that comments would be lost by Subversion on multiple merges. I mentioned that several high profile companies use Subversion and don’t seem to have a problem. The architect said that research was performed and it doesn’t, and if I have a better solution, I should do my own research before making a comment. I told him that software does indeed improve, and that if research has been done, it should be reviewed periodically to see if the issue had been fixed. I did research the issue, and Subversion did have bug but was fixed, and my client could use comments in their merged code. The key here is that the staff complains that changes don’t get done, but when they are in a position to make it better, they don’t do it. If anyone investigates a new technology or work process it should be DOCUMENTED AND REVIEWED! I don’t know if it will be investigated because it seems like a trivial issue, but the main problem is that the application development people complain that nothing changes. It’s our Culture. Culture is people, and all people, especially application development people can change culture. If there are deprecated methods and TODOs in production code, bring them up in your code review. I don’t accept “that’s the way it is” as a reason. You can’t change a decision for business reasons easily, but you can fix how things get done. If I don’t like the way that it is, I make it better.

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……

The Value of Communication

Monday, July 12, 2010 by Matt Warman

There are many skills needed as an application development person to be successful, but none more important than communication. In fact, that is point of our job, to be able to communicate to our peers, partners, and customers. I believe that most organizations make money in spite of the immense lack of communication. Most of the application development people I know complain more about the policies and procedures than about anything else (although it’s always something!). Aren’t policies and procedures communication? Certainly, but it’s the internal communication that enables and drives the external communication. Everything we do has an impact on our ability to communicate. Say the wrong thing to a journalist, and you will be removed. Miss that deadline, forget about the promotion. Governance is important for the security of communication, but when do these rules get reviewed? Ask any software development person or manager why, and the answer usually is “that’s how we do things here”. The real answer is that someone set that restriction to an event that happened long ago, and nobody is willing to change things. If communication is the life blood of an organization, why would we restrict the life blood arbitrarily?  If this sounds like your organization, maybe you need to review how you are handling your communications. If you need help, STAR BASE Consulting has years of experience triaging your life blood, and making it flow easier, better, and stronger.

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.

Business Analyst: The Most Important IT Role

Friday, June 11, 2010 by Aaron Whittenberger
Now didn’t I say that Business Analysis has far reaching impact on the organization?  A new Forrester research report supports my claim as it ranks Business Analyst #1 of the 13 Most Important IT Roles.

The age of IT specialization has been replaced by an emphasis on skills that can translate across the enterprise. According to Forrester, this shift can be traced to a number of emerging trends:

* Maturing technologies such as software-as-a-service and business intelligence are changing IT skills requirements;

* The growing array of outsourcing options have altered in-house staffing priorities, with more specialized skills increasingly likely to be outsourced; and

* The continued search for cost-reduction opportunities has changed how IT decisions are made.

With those trends in mind, here is Forrester’s list of the 13 Most Important IT Roles, based on the percentage of IT executives who believe each role is growing in importance.

#1 – Business Analyst – 70%

Talk about holding all the cards: Not only do these IT pros know the business, they also have their fingers on all the insight.  As the saying goes, knowledge is power.

#2 and #3 – Architecture and IT Strategy/Planning – 66%

As IT has evolved into an increasingly important part of business, both of these roles have become critical in ensuring that every department has the infrastructure and tools that it needs.

#4 – Project Management – 65%

What business doesn’t need people who can mange multiple personalities, master numerous business processes, understand different aspects of the business and make sure things get done?

#5 – Security – 62%

With the onslaught of breaches and identity theft that constantly filters through the headlines, not to mention the growing mandates for better access controls, is there really an explanation needed here?

#6 – Service Management – 60%

The whole thing about the customer applies here to, as managing IT from the customer’s perspective has become de rigueur.

#7 – Client Relationship Management – 56%

We’re in the age of customer service, and anyone who’s mastered the art of managing CRM environments is worth their weight in gold.

#8 and #9 – Business Continuity and IT Financial Management – 55%

With companies paranoid about their systems surviving natural and man-made disasters, and cost-effective IT spending more important that ever, it’s no wonder these roles are on the rise.

#10 – Portfolio Management – 50%

This is a growing area driven by the desire to demystify the measurement of the impact of IT investments.

#11 – Asset Management – 34%

Like other spin-offs from more general business roles, this is another specialized function better outsourced.

#12 – IT Research – 30%

Research? That’s what consultants are for.

#13 – Human Resources (within IT) – 20%

HR for IT is an increasingly unnecessary luxury in an increasingly self-service environment.

Take a closer look at that list and you will notice Business Analysis has been ranked #1, #2, #3 and #10.

Know Your Role

Thursday, May 20, 2010 by Matt Warman

I am finding out things at my current client that everyone, including application development people knows; having a process is only half the battle. I have been to organizations where business workflow processes were not in place, and the productivity gains were huge when implemented. But over time, those processes stop getting followed. There are many reasons for this; the IT culture rejects the change, the processes don’t get reviewed in a timely basis and become a burden, and the players forget their role.
My client has a decent development workflow in place. Analyst get requirements from the business units, architects turn the business requirements into technical requirements, and application development people execute the requirements. Managers should manage the process, making sure that the resources are available when needed. I always wondered why top technical guys get passed over for management in favor of PHB (Pointy Haired Bosses), and now I know. It’s that PHBs know their role. Managers are managing the PROCESS, not the solution. Often, technically savvy managers want to work the issue. Software development is a very fluid process, and what works now, may not work three years from now. If you are manager for more than six months, you probably don’t know the correct solution. Regardless, your role is to make sure application development staff are available for the solution designed by the architects. Managers have a right to review the design during the design phase, but once finalized, let the architects and application development people do their jobs.
The same is true for consultants. Yes, they are using older technology, and yes it’s a pain to use, and yes it needs to be updated. Your job is to help resolve those issues within the framework of their organization. Unless you are brought in as a CIO consultant, the choice is probably not yours to make. It may be that the business has urgent needs that supersede modernization. They may not have the technical people to maintain the new code. The organization could be planning to replace the system with a prepackaged application like SAP. Or it could be that the technical staff knows their role, and is waiting patiently for their opportunity to upgrade.

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.

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?

ROI, Do we have to?

Tuesday, January 19, 2010 by Jeff Welsh

Happy New Year!!!  Welcome to a new year, new decade and a new beginning. 

As the recession recedes and recovery takes hold, IT executives are looking at their project lists and trying to decide what their priorities are.  Should we do application development in house or bring in an IT consulting company?  Should we consider an open source application?   What is the ROI?  What’s a company to do?   It doesn’t matter if your company is in Cincinnati, Dayton or Katmandu, the questions are the same.

Last month we did a pulse survey to see how IT leaders are managing ROI measurement.  The results were surprising and sparked a lot of conversation here at STAR BASE, Inc.  The thing that surprised us the most was the number of companies that did NOT look at ROI before doing a project.   Most of our respondents (58%) do not.

Some of conversations we have had revolved around the idea of doing a project or installing an application just to stay in the game.   Could you imagine a company of any size today functioning without email?  I could argue that there is negative ROI with amount of time managing my email in box takes! 

For those that measure ROI, only about half see the actual ROI align with the projected ROI most of the time.  The other half report that they see the actual ROI align with the projected ROI less than half the time and most said seldom or never.  I have often said that if management knew how much it was really going to cost to install that new ERP system before they started, they probably wouldn’t.

Since most of our respondents don’t look at ROI and of those that did, half said the ROI did not align, my question is this:  How do you decide what projects to do?  Are most companies spending money on IT because they need to “keep up with the Jones’ “?  Is it because installing that new ERP will look good on everyone’s resume?

Get your copy of our ROI Survey results by going here.


 

Run with the Pack

Friday, November 20, 2009 by Jeff Welsh

I was reading this article and as a Cincinnati based IT consulting firm owner, found it interesting.  Social networks are influencing our everyday lives more and more each day.  This research was conducted by Don Bulmer from SAP and Vanessa DiMauro  According to them, there were six key findings:

1. Professional decision-making is becoming more social - enter the era of Social Media Peer Groups (SMPG).
Professionals want to be collaborative in the decision-cycle but not be marketed or sold to online; however online marketing is a preferred activity by companies.
2. The big three have emerged as leading professional networks: LinkedIn, Facebook & Twitter.
The convergence of Internet, mobile, and social media has taken significant shape as professionals rely on anywhere access to information, relationships and networks.
3. Professional networks are emerging as decision-support tools.
Decision-makers are broadening reach to gather information especially among active users.
4. Professionals trust online information almost as much as information gotten from in-person.
Information obtained from offline networks still have highest levels of trust with slight advantage over online (offline: 92% - combined strongly/somewhat trust; online: 83% combined strongly/somewhat trust).
5. Reliance on web-based professional networks and online communities has increased significantly over the past 3 years.
Three quarters of respondents rely on professional networks to support business decisions
6. Social Media use patterns are not pre-determined by age or organizational affiliation.
Younger (20-35) and older professionals (55+) are more active users of social tools than middle aged professionals.
There are more people collaborating outside their company wall than within their organizational intranet.

After reading this, a Bad Company tune came to mind, “Run with the Pack”.  There is certainly safety in numbers.  My question is this:  If everyone is doing the same thing, are they giving up any competitive advantages?

 

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.

My Learning Recipe

Friday, October 30, 2009 by Matt Warman

As a consultant and application development person, I have to learn new things all the time. Take for example, my work with JavaFX. The language does have some familiar aspects, but there is a lot new there too. How do you go about learning something new? I have come up with some guidelines that I use in learning new things (in this case a language):

  • Read as much about it as you can first. No one wants to wade through tomes of technical information, but that is where you learn. I try to get a feel for what problem the new thing is trying to solve first.
  • Understand the core elements. Whether it's a programming language, a car, or a philosophical construct, knowing how it works is the first step. I know it's time to go to the next step when I have some ideas on how to use the item, and I start formulating a project.
  • Examine and breakdown examples, if you can. You would be surprised at how many application development people think they're “smart enough” to figure out how things work just by following a few examples. I don't know about you, but I don't figure out a complex things just from a few simple “Hello World” examples. That being said, seeing how things works is the quickest to way get a basic understanding. Couple that with knowledge you acquired by reading the manual, and you get the “why” of how it's put together.
  • Create your own knowledge base. I like to Google more than most people, but things do need to get done. I will create a separate folder to contain links to examples, other application development team members' blogs, white papers and other documentation. If you can, create a “how-to” WIKI. Having a centrally located repository makes it simple to answer questions.
  • Create a test project. I do this especially for languages. I create a test project where I can test specific “how do I?” questions. It keeps you from removing code, adding unnecessary functions, and commenting and uncommenting code in your main project. Figure it out in its own project first, then transfer the code and knowledge to your main project. It is always good to revisit it after a period inactivity.
  • Write or teach what you learned. As application development people, we tend to get blinders on when doing something. Having a different set eyes, or different questions being asked makes you examine what you actually know.

     

So there's my “Secret Sauce” for learning. You still have to come up with ideas on how to utilize you knowledge though.

Takin’ the Basset Hound to the Farm (Part Two)

Thursday, October 22, 2009 by Jeff Welsh

In part one; I talked about some of the IT Strategies and business strategies that were discussed at the Techserve Alliance conference we recently attended.  I’ll admit I’m a sucker for quaint sayings and one of the speakers had a good one:  It’s time to take the Basset hound to the farm.  So what does that have to do with IT Strategy or business?

Plenty, takin’ the basset hound to the farm means it’s time to re-think what you are doing, why you are doing it, and who is doing it.  It’s time to eliminate products, services, processes or people that are not delivering value to the business.  This is not just an IT strategy, but an important business strategy as well.  It is critically important to make sure both business and IT are aligned. 

The trick is to figure out what your basset hound(s) are.  Every business that has been around for any length of time has one or more of these.  It may be a line of products that are kept in stock because it “rounds out the product line”, when the reality is the items are not that important.   It could be a service that our “customers really want”, but in reality  the service does not deliver value or it could be that “special process” that you do “because we have always done it that way”.  Then there is Bob.  Everybody likes Bob. Bob has been around forever and knows everything.  The problem is Bob doesn’t really do anything.

It’s always better to take the basset hound to the farm on your own terms rather than be forced into it by circumstances.  Take for example the company in New England that manufactured parts for submarines.  When the ship yard closed a few years ago, they were forced to change.  They redeployed their manufacturing expertise and now make parts for the medical industry.  What could they have accomplished if they had manufactured both parts for submarines and medical devices?  Could the business have been double the size?

That’s where an outside consultant can help.  They can be objective and bring an outside perspective to your current business and IT strategy.  STAR BASE is in a good position to teach old dogs new tricks”.  (Who let the dogs out? Who? Who?!)


 

Working with Magento

Wednesday, October 21, 2009 by Matt Warman

People outside of Cincinnati may be shocked to know that I work with languages OUTSIDE of Java! I don't know any application development person, especially one who does web application development who doesn't use several languages. I have recently been working on Magento. What is that you say? Magento is an Open Source PHP ECommerce application based on the Zend Framework. You don't need to download Zend, just the Magento PHP files. We actually have Magento internally setup with a LAMP package, but I already have MySQL and Apache on my local machine, so I thought I'd tackle and individual install. The verdict? Well after a couple of small hiccups (don't use the Windows install for PHP, just unzip, and localhost needs to be a virtual host), setup was a breeze!  Fortunately, STAR BASE, Inc. has enough experience to over come these issues.  Magento is easy to customize products and catalogs, and would be a good choice for organizations to create their own ECommerce site. Magento is easy enough to implement without an IT Consultant, but an experienced consultant can save you time and frustration.


Takin’ the Basset Hound to the Farm (Part One)

Tuesday, October 20, 2009 by Jeff Welsh

Seems like it has been a while since I have had a chance to do a post.  For the last 3 weeks things have been absolutely crazy in our IT consulting world, but in a good way.  We had a chance to go to the Techserve Alliance national conference in Las Vegas.  I have heard all the jokes, including the one about it staying in Vegas.   We did learn that just because you are pre-checked with the airline, does not mean that your bags are.   We got our bags checked with literally a minute to spare and fortunately all made it back to Cincinnati.

Upon return, we signed a support contract for a new customer.  They trust us enough to outsource their entire IT applications support to us.  We have a real life example of an IT Strategy that was discussed at the conference (See #3).  Not only was IT strategy discussed but business strategy as well.  Here are some highlights:

1. Market Differentiation - customers have lots of choices, how will you stand out?

2. Improve Systems and methodology for delivering service- excellence, efficiency, depth of service.

3. Outsource what you can-eliminate the busy work that does not add strategic value.

4. Deal with the economy being slow to recover till 2012, spend your money wisely, hire wisely, fire quickly, and refine what is working, stop what is not.           

5. Build Alliances with like minded providers in different industries and sell collaboratively to serve the customers' need.

My favorite of these five is number four.  Said another way, its takin’ the basset hound to the farm.  I’ll expand more on that in my next post.


 

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.

Light at the End of the Tunnel

Friday, September 18, 2009 by Jeff Welsh

Its good to see Cincinnati and Dayton area companies starting to embrace open source as an alternative to custom application development.  As an IT Strategy consultant, I can say there is a place for both.

STAR BASE, Inc. just landed another Magento project.  I have written about Magento before and this post has links to several others.   These are not your father’s shareware packages. The packages we are working with are what I’m calling Commercial Open Source. 

I’m curious, why have you or your company not implemented an open source option?  Is it because the light at the end of the tunnel looks more like a train?  Maybe we’re just ahead of the curve again and I need a little bit of Patience.