Thoughts on Finding Value in BPM/Workflow Technology

I found an interesting entry on my colleague Todd Biske's blog Finding Value in BPM/Workflow Technology.

Here are some additional thoughts on how the value proposition for the BPM and Work Flow Management tools could be taken to the next level.
1) Ability to incorporate "Rules" or a "Rules Engine Component" into a business process step or a work flow task would be a great addition to these BPM/ Work Flow Engines. These rules can be encoded best practices or they can be regulatory in nature or business algorithms that may be volatile while the process flow or the work flow may not be so.

2) Ability to perform impact analysis for any process flow change prior to releasing the "new process".

3) Availability of analytical tools that could suggest optimization opportunities that could make process improvement suggestions such as the following
a) how switching the steps in the process may benefit the overall process flow
b) how metrics show that there is a ton of waiting in a step that could be made optional based on some criteria
c) how analytics could drive other optimizations such as making suggestions for automation of an information gathering step

4) Ability to subscribe to regulatory bodies that govern the outcome of a particular step of the process flow.

5) Ability to create a business process template for oft used processes within an industry vertical that allow standardization in the overall flow while catering for customizations and competitive advantage optimizations in particular steps of the flow.


Best Regards!!
- surekha,

Have you heard for Ahmedabad? If not - you should

Ahmedabad is the largest city in the state of Gujarat (India) and is a few hundred miles north of Mumbai. This is also the city where Gandhi had his ashram where he start the non-violent movement for freedom from the British rule.

It is very unlikely that you have heard about this city, other than maybe seen it in the Gandhi movie not knowing the name of the City. Based on my recent trip there earlier this year I believe that it has the potential of becoming one of the major International cities in India .

Following is my reasoning:

• The state of Gujarat was hit by a major earthquake in 2001 which resulted in thousands of death and substantial damage to the infrastructure. From this tragedy rose an opportunity (and which I sincerely hope we repeat the feet to overcome the current financial crisis)



• The state and the city rebuilt all the major roads include some highways that are mostly 6 lanes wide (OK the extreme two are now used for parking). Even though there is traffic - it keeps moving and one can go from one end of the city to the other without any major traffic blocks (unlike the other major cities)
  


• In the late 80's early 90's the pollution was horrible, especially at the center of the city where they had the highest level of pollution of any of the cities in India. Today they have provided incentives where majority of the auto rickshaws have switched to CNG (see picture below).


• The city is the banks of river Sabarmati and they have now embarked on ambitious multi year project (SRFDCL) to develop the riverfront on both the banks of the river from one end of the city to the other.


• Even though the traffic is OK now, in order to cater to the growth the city has embarked on one more project of developing a Rapid Transport System (BRTS). Instead of developing a city metro/rail system, they took a faster an more practical approach. The city has built dedicated special center lanes for express bus. In addition, they have also built a number of flyovers to facilitate rapid transportation. Something to learn from, it may be cheaper and faster to develop rapid transportation system using buses than developing a city wide metro/railways.


• The city boasts one of the best Management Institutions (Indian Institute of Management - Ahmedabad) in the country. Ofcourse there is also the Gujarat University (a large campus) with a lot of well reputed colleges and research centers around it.


• Looks like Indian Institute of Technology (IIT) is expanding into more cities, include Gandhinagar (IIT Gujarat) which could basically be considered as one of the suburbs of Ahmedabad

There are lot of other cool stuff about Ahmedabad and if it looks like I am biased - Yes! I am. In the spirit of full disclosure, I spent my first 19 years at Ahmedabad.

What does this have to do with SOA or Strategic IT? Very simple - the State and the City realized that the city was becoming unlivable because they were not providing adequate services to their citizens. In order to improve the quality of service - the combined their efforts to first plan and build out the infrastructure (still WIP) to try and provide one of the best living conditions in the Country. Something we can all learn from.

Key Learnings:Drawing parallels between Design Patterns and the principles of SOA - Part II

This blog entry attempts to expand on the concepts explored in a prior blog of mine Key Learnings: Drawing parallels between Design Patterns and the principles of SOA that deals the relevance of design patterns in the world of SOA and services. Patterns explored previously were the Facade, Abstract Factory, Builder, Factory and Bridge.

In this blog we look at how infrastructure components like the ESB that are part of the service mediation layer insulate the service consumer from the service provider by offering call-dispatch functions that map out the most efficient call execution path for honoring a consumer business request। Many of the constructs of the service mediation layer provide add-on capabilities which are in fact model driven implementations of common design patterns।


Adapter - modifies an incoming method call to fit the required method signature or definition of the provider without impacting the consumer

Transformer - adapts the parameter and return type or message format (which includes alteration or interpretation of the message content) and enables the insulation of the consumer information from that of the providers'

Decorator - augments the behavior or is a facility to add on to the behavior without altering the interface and breaking the service interface and service contract as new consumers need additions to the base business behavior

Interceptor - provides ancillary behavior, filters out information or calls to the provider, validates the message content for authN credentials, authZ/ entitlements and permissions etc। all of which provide important ancillary behavior to the provider without having the providers' service implementation layer having to be peppered with nonbusiness logic level code।

Finally, the point of this blog is to show that despite vast numbers of changes in technologies and technology based service offerings the basic design principles and design patterns of the object oriented design realm are still applicable। Knowing these and applying these carefully enables one to retain the durability of the service interface and protects the consumers from unexpected or non-deterministic results and exceptions.

Thank you for listening. Your input is invaluable!

- surekha

Architetcure in 2009

This will be my first entry into the blog for 2009. It has been a while due to a lot of churn over last few months. I am happy to see 2008 go. The only fear I have is that at the end of 2009, I don’t want to be longing for 2008. What a brutal year. I am hoping that people have learnt some lessons that you can not always focus on short term results at the expense of doing the right thing that has long term value. Architecture falls in that long term value category, yet first thing organizations do when it comes to cutting costs - they sacrifice architecture. Why do we keep rewarding people that cause untold harm in the long run while seemingly achieving short term goals? Most IT organizations fall into the same category. Senior executives are rewarded based on short term gains or operational efficiencies at the expense of long term viability. Current environment will only exasperate the situation.

It seems to me that executives and boards have not met the responsibilities entrusted upon them. Most executives have only been interested in benefiting themselves. I believe that executive bonuses should be kept in escrow and only be handed out at least 3-5 years after they are eligible to receive it. The disbursement of bonuses should be contingent on meeting some tough criteria where it is clear that no long term harm was brought upon by actions of these executives that may have fattened the bottom line in one year but killed the company over long haul.

My apologies for ranting but it has been very frustrating last few months. Now we need to focus on future and adjust accordingly. One trend I am seeing is that without clear, measurable ROI, funding is going to be scarce. There are fewer (if any) opportunities to experiment. This also means that vendors will have to adjust their expectations and will have to prove beyond power point slides that their product is worth investing in.

Happy new year everyone.

Ashok Kumar

Doing a lot more with a lot less in the current environment

Given the current market conditions all business executives are once again challenging the technology teams to do a lot more with lot less. Following are some of my thoughts around this (nothing new - just going back to the basics).

• Focus on solving your customers needs - independent of the industry.
• Do not scale back on innovation. All markets typically are different when they come out of a recession that what they were before one. It is only those who focus on innovation shall come out as winners.
• Focus on your core business - differ the adjacent market until the market recovers (unless it is related to the innovation)
• Do not focus on developing new infrastructure (unless absolutely needed). Build out the infrastructure incrementally as new products and offerings are either upgraded and rolled out to customers.
• Do invest heavily on large packaged applications. As the entire market is going through a shift - it may not be wise to invest in large packaged applications. It will consume a lot of resources (and $$$) without any major differentiation. It may be easier to subscribe for the same applications from a SaaS provider.
• Do invest in a few strategic initiatives
• Do not attempt to crawl before you run - "run baby run". The company that runs the fastest to meet the customers demand WILL WIN.

Just some of my final thoughts to close out 2008 and as usual please do feel free to drop me line with your comments and/or feedback.

Wishing everyone a very happy and prosperous new year.

Yogish

Key Learning from reclycling

Over the long weekend I decided to recycle all the boxes that were in my garage and following were my observations:

• I had not recycled the boxed for a very long time - so it was complete mess in the garage.
• About a decade back you could just put the boxed out and the garbage collectors would take it for recycling - not any more. We now need to break down the boxes - flatten them and stack them in the provided container in a systematic manner - otherwise they WILL leave them behind.
• As I was breaking down the boxed - realized that the technology has changed. It is very easy to flatten and stack them.
• However, there were a couple of boxes where I need to use brute force, cut them and even stand on them to forcefully flatten them. Some of them were recentely manufactured ones - guess they did not use the latest technology
• These days - eveything seems to come in box, no matter what you buy.
• It is important to recycle the boxed on a weekly basis - instead of waiting for a long time. The longer you wait the worse it gets.

Hmm!! - haven't I heard this before? :)

Yogish

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