One of the Architecture Institute’s Board members, Boni Bruno, and I were having a conversation back at the beginning of December about Architecture view points and he brought up something that I hadn’t thought about. He wanted to make sure that the Architecture Institute was taking into consideration ALL architecture view points and not just those from within the Enterprise.
For those of you that don’t know Boni, he’s the Chief Solution Architect for EMC and very knowledgable in both architecture practices and in delivering architectures to clients. And he was very right in bringing that different view.
I hadn’t thought about it because I’m typically working on behalf of clients. While I may be a contractor by nature, I’m looking at Architectures from the point of view of an Enterprise making use of the internal architecture practice. For example, I’m now on a contract with a large manufacturer and I’m now getting to know their internal architecture practices.
But what about the architecture practices of Vendors? How do you look at them in the delivery of solutions to clients and not made use of internally?
When I go back to my Reference Enterprise Architecture, I see two aspects. I see the business areas that are viewed as support services and I see the Core Business area. When I build an architecture or a strategy, I build it for internal use. An internal strategy is focused on the direction that the Enterprise wants to go in. An internal architecture is focused on specific projects delivering on that internal strategy.
So the architecture practice is built around internal consumption of architecture. But what if your Core Business is delivering solutions to customers. How would that architecture practice look? Would it be integrated into your internal architecture practice or would it be separate?
To look at it from the Vendor’s point of view, I have to go back in time to when I was involved in EDS’ porfolios and creating a service for taking to market. This would be back in the 2000 – 2007 time frame so I would suggest that techniques may have evolved and I would love to hear back from Vendor Architects on their approaches.
When we worked on portfolios, EDS had a very good method for creating something for going to market. What we would do is create a partially baked solution, kind of like buying that partially baked bread from the Grocer. You would take that partially baked bread and put it in the oven to finish baking and get a really fresh, crisp, delicious bread. The concept was the same for delivering a service – you would get a really good finished solution.
Most Service Providers, in my experience, seem to create a fully baked offering and what you see is what you get. It lowers the costs to the end customer, lowers the skill level of the personnel delivering the solution, but also reduces the flexibility and ability to meet more of the Customer’s requirements.
When a portfolio is started, what occurred was a review of what the typical requirements are from various customers. If we were lucky enough, we’d have a Customer partner that we could use as a representative of what the market looked like and then build with them in mind (which helps knowing that someone is paying for that initial build). While that sale may not cover all the expenses, it can be viewed as an investment in creating a service that can be delivered to the marketplace.
We’d try to identify the requirements that the customer base would be looking at. That would involved conversations with actual customers, reviewing the market space with someone like Gartner, and doing other research like talking with product vendors. Because, in the end, if we didn’t have a good handle on the requirements of the market, then we risked missing the mark with a go-to-market service.
Having never worked from a product vendor point of view, I would say it looks the same from the outside world. When I was working with BC Hydro, Cisco was the Product Vendor that was providing the Grid Routers (Routers that connect Smart Meters back to the Head End within a Utility). BC Hydro was the Alpha customer for the Grid Routers and, while BC Hydro ended up getting what they needed, there were some changes in direction along the way simply because there were requirements that got missed along the way.
Tells you the importance of good requirements gathering, even when creating a go to market service!
Back to my EDS days. Because we knew that every organization was unique, we’d have to take into considerations what was common and what was unique to the individual organizations and then create an architecture that was flexible enough for the majority of customers but still had a relatively stable core architecture. We’d look at the market place and determine which product vendors had the highest level of meeting a customer’s requirements (including financial) and then build that architecture. We typically focused on only 1 or 2 vendors.
If you are a Product Vendor, I would assume it makes it that much easier simply because you are focused just on your own product and will then use your Professional Services to deliver the product. Your focus is probably more on the products than on the professional services because that’s your core business.
Then, based on that approach, we’d create the templates for the delivery of the solution. Service Vendors typically will be set up so that there is a Portfolio team back in the “Mother Ship” and then there are teams specifically tied to Customers. The good Service Vendors or Outsourcers will have their Customer teams first look at their in-house solutions and then look externally so if you were a product vendor, you’d want to be a partner with a service vendor so ensure you were being designed into the service vendor’s customer’s environments.
It’s where a Service Vendor doesn’t have a Portfolio offering that is the test of their actual architecture practice. Because there isn’t a service that’s been researched and tested and vetted with different customers, a Service Vendor is in the unique position of having to put together Architectures on areas that they don’t typically have expertise in. And that’s the thing that Enterprises that talk with Service Vendor’s have to understand – if a Service Provider doesn’t have a Portfolio offering in a specific area, you are dependent on how solid the architecture practice is. Not on quality of the people because the quality is going to vary and, typically, a Service Provider will put their best professional in front of the Enterprise and then do a “Bait and Switch” when they get the business.
It’s at that point that the Service Provider will need to have a documented process and a set of reusable templates. And, unfortunately, my experience with most Service Providers is that they haven’t figured out that the Architecture Practice itself is something that a portfolio offering can be built around.
There are some exceptions, though. For example, I worked through Accenture with the delivery of PCI compliance for Best Buy Canada. What I found was that Accenture had an extensive collection of templates that they would use throughout the Project delivery process. For each stage in a project, there’d be a template that would be used. The process for project delivery was a PMO process and I didn’t see any ARB or Architecture Governance (at that time) but the templates were really sound. But I learned from that and, as a result, my company uses a set of templates for all Architecture activities.
But, by and large, I typically don’t see a “codified” Architecture practice for delivering a solution to customers within Service Vendors. They have their set practices where are fully baked and that is what they fall back on when delivering a solution to a Customer.
So when a Service Provider is delivering a project and they say that “this is what we typically see being successful in a customer”, that is coming from that fully baked Portfolio offering. It’s when those portfolios have to be customized that things start getting into trouble.
So, remember, when you are dealing with a Service Vendor, before you sign on with them ask to see their documented Architecture process for delivering solutions to customers. They may want to put in front of you the process they use internally but that isn’t necessarily the process that they will use in delivering to customers.
If they don’t have something documented, then you know you are going to have issues when it comes time for them to deliver a solution. And THAT is what Boni Bruno from EMC was talking about. There’s the internal architecture practice and there’s the architecture practice for delivering solutions to Customers.
You have to consider both moving forward.