How to take a Transaction Based Vendor Relationship to the next level?

In the following blog, I talk about "What is the definition of a strategic partnership with a vendor?" and outline a few thoughts on how large enterprises should engage with their vendor partenes and what the expectations of such a relationship should be.  A fellow blogger of mine expressed his "dissapointment" with vendor partners and their focus on selling new product as opposed to helping maximize the returns from the existing IT Assets.

I whole heartedly agree the pressure from vendors can be exasperating.  I was thinking if there is a way to turn this around. What if  as an example, your IT product vendor were told that they would have to provide expertise (at no cost) to solve current interoperability issues or resolve performance bottlenecks between their product and one other product while show casing a operations admin and management/ monitoring tool - OAM tool?  This would be their elite product engineering or premium consulting service participating on-site mentoring your team and not the "support" organization which has to trouble shoot remotely.

Another example, if this is a package solution vendor with a long deployment cycle then the vendor can be asked to offer (again for free) analysis tools or processes or best practices and other accelerator kits that improve speed to market for their product, with the chance to demonstrate components of their next generation product.  Again, the vendor has to part with IP (intellectual property) and address your pain point with the chance to demo a product that would or could be a fit in "your" enterprise.


The result would be the ability to extend or enhance the life of existing investments, while evaluating the vendor product, vendor processes and expertise in a real life scenario.  Most importantly however, you are putting their resolve to test as to whether they are able to or willing to be your strategic partner and not just a transactions based product vendor.

Of course, I would be remiss in not stating that VMO, PMO and your legal departments would have to help with insuring this was a fair and scientific discovery process and also, that the licensing models were conducive to both parties.

As always your comments are welcome. 

Surekha -

Architecture Organization Patterns

Over the past couple of years I have observed that companies from the high-tech industry are adopting two distinct patterns for organizing their architecture team.

Centralized Organization:

• This is true for most IT organizations led by a CTO-IT, VP EA or Chief Enterprise Architect
• All EA members reports to the head of the EA team
• Individual EA are either focused on some core technology, IT functions (such as networks and operations) and Business Domain
• Business Domain Architects dotted line report the head of LOB-IT (typically the Divisional CIO)
• LOB-IT may also have Architects who dotted line report to the member of the EA team

As IT organizations need to focus on what is best for the enterprise - rather than on individual business units, this is a preferred organization structure adopted by IT organizations.

Federated Organization:

• Most of the High-Tech companies have adopted this model for their line business (with IT adopting the Centralized Organization)
  
• Typically there is a Chief Architect for the company who reports to the CTO of the organization
• Evey business unit has a Chief Architect who directly reports to the Head of Engineering of the business unit and dotted line to the Chief Architect or the company.
  
• The Chief Architect sometime reports directly to the GM of the Business Unit.
  
• The GM of the Business Unit and the CTO typically report to the CEO
• The head of engineering reports to the GM or is also the head of the Business Unit (varies - no consistent pattern observed)
• The success or failure of this pattern is directly dependent on the leadership skills of the Chief Architect of the Company
• The Chief Architects of the Business Units also play an important role and will be effective only if they constantly communicate to each other
  

As the GM like to have a sense of ownership - this organization pattern makes sense of the High-Tech industry. If the Architecture team is centralized under one Chief Architect - my observation has been that the GM then hire their own Chief Architect (under some other title) which creates a huge organization conflicts.

Some Interesting Observation:

• One of the companies during the transformational phases transferred all their key resources - including development managers, developers, DBAs, Operations, etc. to the architecture team. Made a public statement that Architecture team was core - reorganized the rest of the teams and later over the three year period transferred the folks back out to the new organization. Using the Architecture team to retain the best resources during their transformation phase.
  
• There is a 50% split between Shared resources team as being part of the Architecture team or an independent team.
  
• Lately over the last 12 months - a lot more companies in the Silicon Valley are looking or Chief Architects responsible for both Business and Technology Architecture. However, they do not explicitly mention Business Architecture in their job description but their job description includes Business Architecture responsibilities.

Just some of my observation about the Architecture Organization Patterns and as usual please do feel free to drop me line with your comments and/or feedback.

Yogish

Best Practice: SOA Development Organization

In early 2006 I had documented my views on how the IT development organizations would change by adopting SOA. I had termed it the SOA Development Organization and I still believe that this is the end state for the IT application development organization.

- Yogish -