Clear responsibilities, clear leadership

As a company grows, new situations arise, and a great deal of effort will emerge to cope with the "new new problem."  After a while, it is not a problem anymore.  However, as the company continues to grow, that 'problem' becomes an opportunity.

Example: let's say you are in a small firm that makes pens.  You are competing with major players like Bic, so you have a niche market.  You make pens that are delivered to companies that personalize them for corporate marketing programs and conventions. 

Along comes a 'problem.'  A salesman figures out that you can make a custom pen designed for cars that come pre-installed in the manufacturing process.  It is a problem because now the pen itself has to be customized, not just the writing.  You develop a process to handle this one-off situation and make some money.  Your sales team takes advantage, and with the blessing of the CEO, goes after every car company in the world to make custom pens to fit in cars. 

And, thus, a market is often borne by the 'sales door.' 

Of course, someone usually forgets to tell IT until after the first 50 orders are already in the door.  Turns out the fulfillment system has a problem.  It invoices the wrong people.  You need to add some data elements and rework the business rules a little.  An IT team launches a project, and you design the fixes.  Maybe you use an agile process.

Then the sales team starts adding features.  You see, they've been hankering for a CRM tool for about a year, and have been frustrated with the slow pace of the CRM project, which you are not working on.  You are working on the fulfillment system.

But they come to you and say "please add these features" and you spot, right off, that the capabilities they are asking for are not fulfillment.  They want the ability to track sales contacts against the customers.  The sales team is asking for CRM features "through the back door."

What do you do?

If you add a few features, just to make them happy, you may slow down the CRM project substantially, because they now have to integrate with your data... data that is in the wrong place.  If you don't, you can make your customer angry, and they are rising stars.  The CEO loves them right now.

This is where Enterprise Architecture is paid to step in and stop the insanity.  EA can review projects, find suggestions for overlapping functionality, and redirect the efforts. 

But for it to work, the dev team has to respect EA enough to call a halt to those features.  They have to back off on those, even though the EA member is not actually a part of the paid project team. 

And that is where you need clear leadership.  Clear committment to quality and excellent operations.  EA needs to be able to talk to the right people and have the right decisions made, and respected. 

A decision to do the right thing may be a difficult decision.  If handled well, it won't hurt.  But if leadership is lacking, or committment to architecture is lacking, then Enterprise Architecture will be labeled as a noisemaker and either the customer or the dev team, or both, will write EA off as a waste of time and effort.

Don't let that happen.

When you join a team, find the lines of leadership and establish your role.  Explain that you may be called upon to change the scope of overlapping projects, and that you will need their support.  Prepare the leaders.  The day will come when you will need them.