Enterprise IT architecture

There are lot’s of discussions about what enterprise architecture is, how to define it, what it does and what not. Not only there are many views and disagreements, it looks like definition doesn’t seem to be very useful to all. Past few years I was trying to follow discussions about what it does rather than what it is. Now I made my mind about it and I have a very pragmatic view of it. Let me explain.

Almost everyone I follow agrees that enterprise architecture is not an IT function and it shouldn’t limit its activities in IT scope. As a direct result, there are two different architecture disciplines: “Enterprise Architecture” and “Enterprise IT Architecture”, Enterprise Architecture being a higher level function covering IT architecture, business architecture, brand architecture, etc.

Before going further into enterprise architecture, I want to highlight some problems within the IT architecture definitions. Inside IT there are architects specialized to a single IT domain such as software architects, data architects, security architects, etc., and there’s also an enterprise IT architects which is not specialized in any of these but have the role of linking them with each other. Theoretically it makes all sense: several specialists and a generalist linking them. Enterprise IT architects therefore do not work on low-level architecture of any domain, but they work on high-level architecture. In practice, this becomes a big problem. Because there’s nothing called “high-level architecture”. There are several levels of architecture, you can check Zachman EA Framework. Enterprise IT architect needs to agree with all architects on who is responsible for which level. How does this work in practice? There are problems:

• Zachman EA Frameworks describes 6 layers. Separation of these layers are not very practical in practice and usually some of them are merged or skipped. So, in reality the distinction between layers are not always as clear as Zachman describes. Therefore agreeing in responsibilities become more difficult.

• Practically it’s not possible to divide responsibilities of layers to different people. Creating architecture is not deterministic process where each step can be isolated from other. This kind of Taylorist view doesn’t make sense for architecture. In reality usually a single person does all the layers which is relevant to architecture. For example, a software architect needs to understand the business requirements from the highest level view so that he can create a physical application architecture.

These problems results with an inherent conflict between enterprise IT architects and solution architects (such as software, data, security, etc.).

I suggest enterprise IT architect’s responsibility is not doing solution architecture at all. Solutions must be done by solution architects.  Enterprise IT architect is not responsible for the solution at any level.  So what does an enterprise IT architect does?

• Translates the IT strategy to each IT domain. IT strategy is not on a level to be directly used by engineers nor architects. An enterprise architect is responsible for creating tactics which can be applied in the solution architecture.
• Links IT domains to each other. When a change in IT requires intensive co-ordination between multiple domains enterprise IT architect can align solution architects from different IT domains with each other. However, it’s important to note that this alignment cannot be done by creating solution designs, it must be done by translation of strategy, definition of principles, etc.
• Creates architecture governance. Translating strategy and giving guidance is not sufficient. Enterprise IT Architecture is not a management function therefore doesn’t have any enforcement on application of strategy. Enterprise architects must define what is most important for senior IT management and therefore must be governed.

This view of enterprise IT architecture can be directly applied to enterprise architecture as well. The only difference is that it’s not IT strategy but business strategy. It’s no IT governance but just governance. But what needs to be done is very similar. Artifacts to be used are very similar as well.

B2B, Enterprise Canvas and the big picture

I’m using enterprise canvas  since Tom put it out there and I still couldn’t figure out this problem with modeling the relations of B2B business model. Now I have a little better understanding of the problem and I think I can describe it here so that you can help me to find a solution.

As I don’t have a business education, I was always troubled by what is B2B. In Wikipedia  it is described as “commerce transactions between businesses”. Well, here I mean something completely different (help me if I’m completely lost). I don’t think that if you sell a product to another company you can define your business as B2B. That would still be a B2C business where a company is in the role of the customer. In a B2B scenario, your business has a direct relation to customers of its customers. Let me give you some examples:

• Company A – Online hotel booking: A traveler searches for a hotel in Company A web site and books a room in a hotel. Here hotel is the customer and it’ll pay a commission for the reservation. Traveler is hotels customer. Company A provides the relation between traveler and hotel to the hotel.
• Company B – Call center: A credit card owner calls customer service of the bank to unblock her credit card. Credit card owner is the customer of the bank. Bank is the customer of call center and will pay for the service call center did for the credit card owner.
• Company C – Payment provider: An online-shopper buys an item from the website of a local store and makes a payment with credit card. Shopper is customer of the local store. Local store is customer of payment provider and will pay commission for the transaction.

In all cases there’s a direct relation with customers of customers.  Immediate question is how to model this relation with enterprise canvas? Well, so far I’m convinced that they are suppliers. At least, this is the most suitable place I can place them. They’re definitely not customers, they are not the one’s paying for the value provided. They are not getting paid as suppliers neither. But when we are talking about value chain, we must be careful about what kind of value we are talking about. In this case the value provided to them is not financial, it won’t show up in the accounting system. But failing in this relation can be very dangerous for all value chain.

My problem is the missing link between these two very important roles in the model: customer and customers of the customer as supplier. For a B2C business there’s no such relation, it’s not important at all. Simple examples, being about simple B2C businesses, doesn’t show anything missing in the model. Take a look at the Business Model Generation book. There is only one example in whole book which I can say is B2B is the Google search and you can see “customers of Google” in the list of customers. Business being based on online ads, how does that make sense???

But is this relation really important?  Let’s go back a little and look what does it tell us. All companies I listed above are doing a B2B businesses with their customers. Let’s turn the picture around and look from the customer point of view. They have their own value chain. Take Company A case, hotel has a value chain where traveler is the customer and Company A is a supplier. Company A is providing a service (mainly customer relations). So can we say those businesses that have a supplier relation with customers of their customers appear as suppliers of services in their customers value chains? This means there’s always a bigger picture. Payment provider will define a vision about making payments easier, cheaper, etc. But it’s business is just to make another business work. Does that mean some enterprises are _fundamental_ than the others? In the real big picture, when we think about a community, what are most fundamental enterprises? Do we live for a purpose? 🙂 This one is a joke, but you see where this one is going when we start to think about bigger picture.

Summary:
– Some businesses have an inherent relation with customers of their customers which is not modeled in enterprise canvas or business model canvas,
– How do we model this relation and showing relations to other enterprises? Can we use existing frameworks or do we need a different one?
– What are the effects of such relations in the big picture enterprise architecture?

Any comments, anyone?

Business Model Canvas and Enterprise Canvas

There are some discussions on connecting business architecture to enterprise architecture. It looks like everyone somehow agrees that Business Model Canvas from Osterwalder somehow needs to be connected to enterprise architecture models. As I spent some time already for creating business model with Business Model Canvas and enterprise architecture model with Enterprise Canvas from Tom Graves, I want to share my opinion.

First of all, although both models are talking about very similar things like organization, business, customers, partners, value proposition etc., they are telling really different stories. The mapping between them really helps understanding the modeling process when someone is familiar with one diagram but not the other. Other than that the mapping can be a bit misguiding and create impression that it’s two different ways of telling same story. It’s very common that people think they’re a little different version of same thing. So what’s the difference?

Well, first of all Business Model Canvas is about telling a story on how an organization is creating value for its customers, to be blunt how it makes money. Business Model Canvas is very useful for modeling the revenue and costs structures around customer and value proposition. So if you are interested in telling a story about how your company will make money with whatever it’s doing for it’s customers, you have Business Model Canvas. It’s not about how things are done in the organization but what needs to be done to make it work.

Enterprise Canvas on the other side is about telling a story of how organization (in the context of enterprise) is structured to do it’s value creation. The key word is the ‘structure’. If you want to understand what needs to be actually done in your organization to create value in the enterprise for the customers, which capabilities are needed, what are the external influencers, you have the enterprise canvas. Important point is that, enterprise canvas  is not about showing how organization is making money. In the enterprise context, it’s not about making money anymore. It’s about a vision, it’s about creating value in the enterprise.

In the enterprise canvas, we’re telling a story about how capabilities are structures to create value. In practice, when you get a post-it in your hand to put on the enterprise canvas, you write a name of a capability there. One important difference between two canvases is that enterprise canvas is recursive. So when you’re writing a name of a capability in your post-it, you need to make sure that capability belongs to the level you’re working one. Although some capabilities are really very important for the organization (costly, high focus,…), they may not appear in the canvas you’re doing for the first level which shows the relations with other parties in the enterprise. On the other side, Business Model Canvas is not about recursiveness, you need to show what’s important there. You can put any capability as a key activity or a key resource if it’s inherent to the business model, independent of the recursive levels. Here the most important this is to create a story of the business, not creating a model which reflects the structure close to reality. So whatever helps you to describe the business model as a story has a place in the Business Model Canvas.

Another important difference is about the partners. But before going into that I must make myself clear about what a capability is. Capability is the quality of being capable of doing work (or performing actions). It is not what is performed in business processes, it’s not what’s done to create value. Capability is what is needed for doing work/performing action for creating value. For example, I’m capable of creating business model and this is also my function in my organization. I’m also capable of translating documents, but this is not what one of my functions in the organization I’m working in. So in my definition, capabilities are not performed or delivered but simply possessed. The Business Capability definition in the Enterprise Business Motivation Model of Nick Malik is more like a Business Function to me, not Business Capability.

It’s possible and very common that some of the capabilities needed for creating value does not exist in the organization. Organizations rely to their partners for delivering them. In Enterprise Canvas it’s very important to show all capabilities, independent of who has them: an organization unit, a single person, a software, a machine or a partner. In case it’s provided by partner, one also has to think about supplier channels and supplier relations for the particular capability. In the Business Model Canvas the focus is not on the structure of the capabilities for delivering value, but what organization does to deliver value. So the capabilities supplied by the partners will not make it to Value Proposition, Key Activities, Customer Channels etc. If the provided capability is inherent in the business model, supplier should find its place in the Key Partners, otherwise not., that’s it. A side note about suppliers in Enterprise Canvas. I always group them into two: capability suppliers and asset suppliers. The difference appears to be very important.

Business Model Canvas models an organization from a particular view, a one which is generally a more familiar view to many. Enterprise Canvas models a different view on a larger scope. This vie w is not very easily understood, not even by most of the directors. When people are talking about vision being making money,  profitability being strategy, etc. it shows lack of understanding enterprise architecture scope and being too much business centric.

Where’s the money in the strategy?

We all hear about management pointing to the ROI, sustainable profit, financial growth etc. in their mission/strategy statements. On one hand it sounds really logical, company has to make money to survive. On the other hand it somehow sounds strange, how making money is related to our vision? Do we wake up everyday thinking we’ll make more money today? Is it really the meaning of life? Something doesn’t fit…

Organizations have to come up with some statements which summarize its intention and motivation. Usually these statements are communicated as vision, mission, strategy, goals, etc. Coming up with such statements is not rocket science. Everyone is doing it. However, it’s not very easy to create a strategy which organization can really use – not only as a motivation statement, but also for doing modeling, planning, executing, controlling. It’s also not very easy to create a strategy which will lead to success – perfectly execution of a strategy may lead to failure as well, this is where business skills and innovation has big role.

Modeling the strategy starts from vision. Vision is the anchor, everybody in the enterprise agrees on it, not only the organization but also the customers, partners, regulators etc. Vision is a three word statement and it doesn’t come along. Together with the vision, values of the enterprise must be defined, too. Once the enterprise vision and values are defined, role of the organization within the enterprise needs to be defined. Every actor in the enterprise has a role, so does the organization. Mission statement is then describing how the intended role will be fulfilled. Success of the mission is measured by goals – ends which are measurable.

All of these statements must be connected. One can not define a mission like “we here to sell insurance”.  Mission must connect the vision to day-to-day work. It must guide the organization towards a goal of achieving something. Organization may fail because goals are not achieved, and may be goals are achieved but the strategy was not good enough. Strategy must direct organization towards success. As one cannot make a mission like “go and make a profit”, there cannot be goals like “increase profits”, “sustainable profit” etc. These kind of statement shows the failure of making strategical decision and leaving organization in chaos.  With no strategy provided, middle managements of the organization are either lost in chaos, or try to make their own strategies which is also destructive for the organization. Survival is not possible if every department in the organization have a different target, different values etc. The worst thing is that it’ll all appear that everybody is following the same strategy “making-money”, and going towards same direction. You’ll always see that there’s something wrong, but never can find what.

Shareholder value, revenue, profits,.. all these financial indicators are not there for measuring the success of day-to-day work, but for measuring the success of the strategy. Therefore has no place in strategy, mission statement, goals, tactics.

Technical Debt

Technical debt is a concept introduced in IT systems to tackle a very simple problem. Over time, quality of IT systems decrease because of the short-term tactics. (some discussions in infoq)

Short-term tactics causes business decision which forces IT organization to build systems or adopt them in a way which is not wanted by IT organization. As a result IT systems are not ideal, they’re not in the quality IT organization would like. Common symptoms are difficulty of maintenance, low flexibility, low extensibility etc.

It’s not only IT organization who suffers from the short-term tactics. Business also suffers. They are left with IT systems which are difficult to adopt. They’re blocked them to implement new products or processes. This is very dangerous, even self-destructive.

Well, solution is easy, according to some. Let’s measure the technical debt, so that we’re not blocking short-term tactics, and in the same time making sure decrease in the IT systems are transparent to business and they have to pay for it.

There’s a very fundamental trust problem here. IT doesn’t trust business to make decision which will not recover the damage made by the short-term tactics. Business proves their inability to stick with short-term goals. That’s one side. Business doesn’t trust IT to deliver systems which can help them to achieve long-term strategies without compromising short-term goals. Whoever is trying to solve this trust problem by introducing a ‘technical debt’ concept is making a big mistake. The fundamental problem is the problem of trust here, not quality of IT systems. Trying to increase the quality of IT systems without solving the trust problem is doomed to fail.

For those who are now interested in measuring technical debt, I recommend to work on the trust issue. VPEC-T framework is a good candidate to start tackling such a problem.

Top-Down vs Bottom-Up SOA

InfoQ fired the debate again. When I looked at my past, I see myself sometimes on side, sometime on the other side. Almost exact debate exist between centralized vs decentralized.  Same story. Now that I have more structured thoughts, I can share them.

So, the problem here is not SOA should be top-down or bottom-up.  We need to focus on what needs to be bottom-up and what needs to be top-down. My approach is to go with the layers. Take Zachman, when you look at the upper layers (Scope, Business, System) are more top-down, and the lower layers (Operations, Implement, Develop) are more bottom-up. Of course the line is not very clear, in the middle (System, Develop) bot approaches meet each other.

Depending on the area of interest, people choose different side on the discussion. Bill de hÓra argues SOA cannot be top-down because there’s no top, SOA systems are in reality decentralized. Of course, when he’s talking, he’s thinking about web services, applications, RPC protocols, REST etc. All about implementation of services. He’s 100% right. On this level, decentralization is the key. On the other side he’s failing to understand when John Crupi is telling SOA must be business driven, must be top-down, he means we start with vision/mission, strategy/tactics, not by technology. He’s not talking about implementation, but scope, business and system in Zachman. There, to have top-down approach is the key.

So my conclusion is people either cannot express what they’re talking about and assume everyone else is in the same layer or fail to understand there are different layers and there’s no one approach to use in all of them. As I experience everyday, latter is more common.

Dealing with complexity and uncertainty

I found some time to look at IBM’s last CEO Study which is named “Capitalizing on Complexity“. The main focus of the study is the increasing complexity and how to CEO’s are dealing with it. They categorized some of them as “Standouts”:

Today’s complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it. Seventy-nine percent of CEOs anticipate even greater complexity ahead. However, one set of organizations — we call them “Standouts” — has turned increased complexity into financial advantage over the past five years.

Big differences between the Standouts and the others are:

• Decision style: (54% difference between Standouts and others) “… quick decisions even when facing uncertainty.”
• Simplify operations: (30% difference between Standouts and others) “… the need to simplify their operating
  strategies in order to better manage complexity.”
• Business model innovation: (81% difference between Standouts and others) Types of business model innovation considered:
  • Enterprise model: Specializing and reconfiguring the business to deliver greater value by rethinking what is done in-house and through collaboration.
  • Industry model: Redefining an existing industry, moving into a new industry, or creating an entirely new one.
  • Revenue model: Changing how revenue is generated through new value propositions and new pricing models.

My conclusion is very simple, who’s dealing with increasing complexity and uncertainty in a better way can innovate more, this is the key for success.

Microsoft and Enterprise Architecture

Mike Walker answers the question very clearly in his post:

– Does Microsoft have an EA framework, methodology or a EA product?

– No.

He explains the “Enterprise Architecture Toolkit (EATK)” is not a framework but just one tool in the EA Toolbox. Here’s some disappointing bullets I noted from the alignment between TOGAF and EATK:

3. Create Architecture Models

There are a variety of activities have to occur to create architecture models.
1. System Architecture Document – First you need a place to describe those modes. The EATK uses the System Architecture document for this task.
2. Visio – Most architects and developers use Visio to model their architectures. The EATK has linked valuable information from the AMR so that the shapes in the model link to real assets and patterns.
3. AMR Pattern References – The AMR provides the facility for storing assets and building blocks that an organization has standardized upon.

B. Business Architecture

Supports the document management and workflow aspects however there is limited automation to these tasks.

It’s also very unfortunate that Microsoft sees enterprise architecture as an IT practice that encompass all of the various IT aspects and processes. Tom Graves explains enterprise is bigger than the organization, let alone IT, and enterprise architecture cannot be it practice. Gartner also identifies this as one of the pitfalls of enterprise architecture.

I wish we could see Microsoft more business oriented rather than technology oriented. Unfortunately this became a pattern for them despite community feedback (here on oslo, here on workflow foundation, …)