Thursday, May 29, 2008
by Burc Oral
There are many ways to encounter the competition in the market place. Among my observations are many: leveraging product or brand characteristics like first-to-the market, best-of-the-breed, cheapest, etc.
I would like to add another one: Gorillazation. What is that?
Simple. Make it such a big, impossible endevaour that entry to the market is deterred. Show that you need a 800 pound gorilla to do the task. It must be complicated because we need humengous infrastructure, development teams, operations etc.
So, just happed that SOA was among the victims of gorillazaton to the point of utter complexity with dozen of standards which are still incomplete. What happened to KISS!
It was kept in the dungeons with the CORBA and was purely technical. This "technical" aspect dubbed SOA as Web Services and made it add a few pounds on the gorilla.
Less business awareness--because it is the techie gorilla-- is an effective way to keep competition away.
How about cooepetitive business environment: compete and cooperate. Our financial industry has been doing for a long time. Every penny eventually circulates across many financial institutions not because it likes to do but it is in its nature. So, fnancial organizations, for instance, communicate through clearing houses, check fro credit, transfer in-kind, etc. These are all commoditized services.
SOA is nether a complex beast nor a 800-pound gorilla. It is true that it tunes differently for many people (See SOA Many Things). When communicated well, Showever,OA can be easily understood and can gain alot of fans at the corner office.
Consider the relation between two verticals: time&attendance (T&A) and point of sale(PoS) . An employee entering her id at a point of sale (PoS) terminal can easily be used to verify attendance. This inherent relationship is the tip of a very powerful interplay of systems and can be expressed as a series of services between T&A and PoS. Often, the vendors are different in an organization. And, more frequently, after mergers and acquisitions, an organization can have multiple systems of T&A and PoS. This where business stakeholders do not want to incur costs due to rigidity of the applications and look for solutions that are pluggable and friendly to the world. Service-Orientedness with its implementation agnosticism becomes the valley of comfort.
Now, while there is a fierce competition in T&A and PoS vendors, they must talk to each other in order exchange information. Cooperation starts well with
When business stakeholders contemplate how to make systems work together, there is no room for gorillas!
Next, we will talk about democratization of business interplay as a direct out come of SOA.
Wednesday, May 28, 2008
We can all agree that the purpose of any Architecture is to manage change. In order to manage business change effectively, we need to understand how a business is designed. It is this understanding of the design of business that is essential in managing business change. Additionalyy, there must be active management of a business design otherwise business design has very little vaklue. The bottom line is that some form of business architecture exists in every business simply due to the fact that a business is operating, producing goods or services and serving its stakeholders. What is generally missing is the formal representation and management of the business design.
I would propose that Business Architecture therefore is both formal representation of a business' design and associated processes and organizational structure to manage the on going evolution of the business' design. The question is what is the right way to represent a business design. A number of approaches are available including Process Modeling, Business Motivation Modeling, Value Chain Analysis, Six Sigma, Lean etc. Similarily what are the right processes and organizational elements that can yield an effective business architecture. I dont thins there is a single answer to this questions. We will explore this further in future postings.
Tuesday, May 27, 2008
Following is an example of a simple Business scenarios:
- In order to increase it's revenue Business Operations would like to learn more about the customer - to identify opportunities for cross-sell/up-sell.
- They approach their partners - typically their preferred SI and/or their preferred software vendors.
- Depending on the vendor (including SI - their resell relationship with the ISV) they would recommend a Data Warehouse, Business Intelligence, EAI and/or Master Data Management Solution. In addition, they will also be willing to guarantee, typically as a fixed bid, implementation within weeks/months (typically 3 to 6 months).
- Business buys into it - spend the money and a year later had not yet achieved the end-result they were promised.
- Vendors focus on delivering an IT solution (generate the revenue and move on to the next project) instead of solving the business problem
- As part of every engagement - both the SI and ISVs need to insist on conducting a Business workshop (prior to starting the IT implementation).
- Provide real-practical advices - example: for a customer master the vendor typically looks for decision from the business to provide them with direction on where to add the customer - Lead Management, Opportunity Management or Order Management. As the vendors have done multiple implementations - shouldn't they know the best practices in the vertical and recommend the approach?
- SI typically have separate organizations that deal with business transformations and IT (CRM/ERP )implementation teams. Shouldn't every engagement have folks from both the practices at the customer site during the initial stages? Agreed the engagement cost will be a bit higher for the customer - but the value received will be substantial greater than the up-front cost. I for one - would be willing to pay. My problem was that no one approached me with such a proposal. However, I was lucky - my CIO recommended (and funded) that I have a full-time architect(s) from an SI on my team.
The above example is based on my own experience and the case study is available here. As the case study indicates - I had to solve the same problem twice. First implement and learn from my mistakes and then repeat it again later. If we had real advice - we would have got it right the first time.
I used these slide to start the discussion on the need for developing an EA road map and also help increase by headcount to include Information and Infrastructure Architects for which I had no coverage. Yes! I did get the incremental head-count.
As reference you may also want to check my previous blogs on:
- Best Practice: Establishing EA teams
- White Paper on Business Architecture
- White Paper on the Role of a CTO
Wednesday, May 21, 2008
My own opinion (misplaced it might be!!) is that ESB vendors tend to bundle a lot of "service creation"utilities and "adaptors" into the base ESB stack, in an attempt to achieve "product differentiation". This very act causes ESBs to become both ridden with "service behavior" which may also lead to "slow performance" of the ESB based mediation. The reason being that it becomes very difficult to performance tune an architecture component that is doing multiple things - it breaks the rule of "high cohesion" in doing "service mediation" and "service behavior execution"!!! The former is a high through-put pass through activity while the later could have fairly intense computation business logic or data processing logic.
Now back to the ESB vs. SCA topic.
ESB - promotes the abstraction of the service provider from the service consumer. Here it is assumed that the goal of exposing the service provider interface is to enable the reuse of the service provider business behavior. ESB' core theme being service mediation.
SCA - promotes the abstraction of wiring in of the external resource dependancies and external transport protocol bindings from that of the core and reusable business behavior of the service. Here the assumption is that the component parts of service provider can be re-assembled in various combinations to assemble services that are invoked from multiple consumer contexts. SCA' core theme being service assembly.
ESB enables service interaction/ mediation from multiple service consumer contexts while SCA enables service provider component parts to be assemble for "servicing" multiple service consumer contexts.
In both cases, the attempt is to decouple service usage from reusable service behavior.
Your comments on this topic are invaluable.
Monday, May 19, 2008
- The EA team establishes standards and primarily acts a police for the enterprise mandating that all business units/projects comply to the standards.
- The LOB-IT completely ignores the EA team and makes it's own decision (does not care about the EA team) and most of the time, it is not compliant to the EA standards.
- EA team not involved in implementation of any strategic projects by any of the business units.
- Constant churn in the EA team
- No existing Enterprise Architecture team
Following are some of the key learnings based on my experience:
- Do not out source the entire EA function to a single SI, especially as this would conflict with the dual objectives given to the acting EAs. One given by the customer (develop the most optimum Architecture) and the other by their employers (generate as much services revenue as possible). For organizations where EA teams do not exists, it definitely makes sense for bring in an SI to run this function and later hire people to develop this capability in-house.
- Keep EA management function in-house.
- Have a dedicated EA from one of the major SI as part of the team. This is to bring outside perspective and also a resource who could tap into the SI vast knowledge bases and resources. Based on the budget - I would be tempted to have two EAs - one from each of the major SIs providing services. Competition breeds excellence.
- Have at least one dedicated EA from your major vendors (software, hardware, network) that provide mission critical capability. Negotiate the rates and the resources before signing the major deal and please do not accept the vendor sales commitment to have a dedicated pre-sales resource assigned to the account. Put it into the contract.
- Have the lead technical resource from each of the major initiative be part of the EA team. Example: An SI may be developing a Supply Chain solution and in this case - the lead architect from the SI for this project should be part of the EA team.
- Engage part-time vendor resources on an as needed basis. Example: Once the content management solution is deployed globally, engage the vendor architect to review all major changes.
- Establish a Business Architecture team, ideally from a Management Consulting company or SI that is not providing the technical architect resource to the EA team.
- Establish, communicate and update EA standards, processes, governance, roles, etc.
- Be transparent - i.e. share your budget as well as all vendor proposals with the entire team.
Agreed this is contrary to the popular opinion - but something that could be pulled off with the right leadership.
Friday, May 16, 2008
Read more about this at my IT toolbox blog here.
Tuesday, May 13, 2008
I completely support this opinion in that if left "unchecked" - read without the right level of governance - this could turn into a maintenence nightmare (not to mention a regulatory hazard especially if the regulatory policies are not implemented uniformly across all versions). But then this is a case for having governance and not an argument against supporting service versioning policy.
I attempt to outline some reasons for defining and publishing a "service versioning policy" to support both the business need and to create an efficient resource-utilization operating model. A carefully thought out strategy of service versioning that is rigousously "governed" allows us to do some of the following:
- support multiple versions where in business functionality may be altered based on the operating business context or business area or industry vertical
- support multiple versions based on the user community needs (for example, invoking a service that incorporates work-flow rules vs. needing a service that is invoked as part of an automated process level interaction)
- support multiple versions that allow an enterprise to reduce the risk to the business when introducing new business behavior or new business process optimization changes
- support multiple versions of a service that allow the enterprise to incorporate and interject additional authorization, entitlement and audit related rules that change based on the business context and/or business user role
- support multiple versions that allow the system administrators to provision server resources appropriately based on the QoS/SLA needs of the service consumer and the service contract definitions.
- support multiple versions of a service to isolate more expensive business behavior calls to specific versions so as to reduce impact to all of the other consumers (For example, a version with externalized business rules while the business is "testing" a new rule would be less performant than a version where the business rule is ratified and encoded into the business logic layer. In this example the business behavior is externalized making the service version more flexible but this makes the service less performant)
Finally, I think that service versioning can be used as a strategy to both support the business need and to optimize resource utilization that in turn make consumer interactions more efficient. Thus, the "appropriate service version" is invoked based on the "right" business context.
Your comments on this topic are invaluable.
Tuesday, May 06, 2008
The objective of this Opinion paper to briefly describe my views on the role of the Chief Technology Officer and is roughly based on the white paper Role of the CTO: Four Models for Success by Tom Berray (Primary Author) and Raj Sampath (Secondary Author). Unlike their white paper in 2002 where they categories the CTO’s into four categories, my opinion is that in this current age CTOs need to have all these attributes.
Please click hear for the Opinion Paper.
Thursday, May 01, 2008
On an average I already have 7 hops for providing my customer the relevant information whenever they login to my web site. Based on your reference architecture recommendation I would increase the number of hops. What does that do to the performance? Isn't that adding one more layer to the current architecture? - Chief Architect of a large Financial Company
Our strategy is to grow by acquisitions and with each acquisition we increase the number the data centers, each having thousands of Servers. In my opinion we are one acquisition away from disaster and you expect me to tie it together by leveraging and ESB? Why shouldn't I stay with my existing messaging infrastructure? - CTO of a large transportation company.
At the same time, to be competitive vendors are starting to include additional functionality into the ESB that do not belong there. In short, making it heavier requiring additional resources to implement the solution. Vendors have now also started pushing embedding ESB into each of the products (not a smart move).
In my opinion the ESB shall be irrelevant by 2010 for the following reasons:
- There is a push by end-users and vendors to develop standards (SCA) to decouple the business logic from the bindings. I expect this to result into a meta-data driven (SCA) container both for exposing services as well as referencing (invoking) services.
- Even though the some vendors do not yet decouple the logical name (such as "Credit Card Approval for Mortgage") from the physical name, the market will drive them there.
- As services are deployed into production, the SCA container shall leverage P2P technologies such as JXTA, Jini, UPnP and/or WS-Discovery to dynamically discover the dependent services. Newton is a prime example of such a container
Of-course like all previous waves and ESB will not go away but be used to interface with existing legacy systems. As for J2EE/JEE - they would still be the technology of choice for some of the SCA containers.
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed a...
In this blog my attempt is to provide some definitions and in turn to get feedback on the differentiation between the parameters traded betw...