Archive

Posts Tagged ‘SOA’

B2B, Enterprise Canvas and the big picture

January 16, 2012 2 comments

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?

Advertisements

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.

Service Reuse

June 3, 2010 2 comments

Reuse is a topic which confuses a lot of people. Main reason for confusion is inability to understand the difference between component-based and service-oriented architectures. These have fundamentally different ways of reuse.

In component-based architecture, the idea is writing components with generic interfaces which can be used in different scenarios. So instead of implementing functions over and over, create a generic/abstract interface and reuse the function in different places. This works in different levels such as simple libraries (log4j, log4net, spring, etc), it works in large frameworks (drools, jpmn, workflow foundation, wcf, lucene, etc.) and also in infrastructure level (database servers, distributed caches etc). The idea is all same: generic stable interface, high configurability. Although this approach works very well with infrastructural components (doesn’t deliver business value directly), unfortunately, experience of the industry shows that it doesn’t work well with implementation of business processes (usually called as “business logic” in the language of this architecture style).

In service oriented architecture, reuse has a completely different meaning. Reuse of services is about existing consumers using newer version of the service. Reuse of services is “forwards” (existing consumers using new service versions) not “backwards” (new consumers using existing services). It’s not about how to implement generic services which doesn’t need to change for new consumers, it’s about how to implement services which can be extended without disturbing (upgrading) existing consumers. Therefore service compatibility and contract versioning are key concepts in service oriented architecture.

A weak understanding of services ends up with, for example, efforts to define generic service contracts. Because it’s practically not possible to know the unknown these efforts are just wasted. Usually this becomes guess-work, future-predicting. David Chappell says “Creating services that can be reused requires predicting the future…” and concludes that SOA doesn’t work. It’s very clear that he doesn’t understand the concepts of service-orientation. Similarly when Juval Lowy is excited about the capabilities of WCF and advertises the concepts “every object as a service”, same mindset presents itself. It’s not difficult to guess why WCF still doesn’t have contract-first web service development.

I noticed an InfoQ presentation “Expressing Service Capabilities Uniformly” which explains reusability as “multiple services implements same contract”. Funny that change of service contract is stated as a problem, and in the “cons” list you can find the difficulty of  change management. Of course, he doesn’t mention a word about versioning or compatibility. With his architecture style business process is reduced to “moving data from service to service” and REST is the savior. Same story over and over again…

Long story short, there are lot’s of people around who doesn’t understand service-orientation but claim it doesn’t work. Reuse is just one example. More to come…

Business Entity Definition Language from IBM

April 27, 2010 2 comments

Last week IBM published the first part of a Data4BPM series:

Part 1 of this series introduces the concept of business entities as a means of representing the business view of data. It proposes two new standards, the Business Entity Definition Language (BEDL) and BPEL4Data for the holistic design and execution of process with Business Entities.

This is definitely a good move towards embracing the importance of data model in business processes. I see this in the direction of connecting different models with the efforts from Ksenia Wahler in her paper “LinkA framework for integrated process and object life cycle modeling” and Bruce Silver in his articles “Integrating Process and Rules Part 1Part 2“.

As mentioned in the paper, instead of “process-first” or “data-first” approach, a “holistic approach will prove to be most effective. However, I don’t agree that holistic means process plus data. For me holistic would as well include business rules, motivation, etc. That would be modeling all columns of Zachman framework (what, where, how, …) For example “Discovering Business Entities” section is very weak, doesn’t tell one work about business rules. You can also see that state transition rules are fit into a single attribute inside access policies. This clearly tells me, there’s a lot of space for improvement in business rules area.

What I like very much in the paper is the concept of four components of Business Entity types:

  • Lifecycle
  • Information
  • Access Policies
  • Notifications

CRUDE style in access policies (create, read, update, delete, execute state transition) somehow matches REST style which could be applied in this context. Although REST is not an approach I would take for implementing services, data services as such could be a candidate.

The link with BPEL is another point of criticism. JJ made some comments about that in his blog:

Thinking that a “Business Process Whatever Language” needs extensions to deal with Human tasks or Process Data is not just comical, it is ludicrous […]