EA - Enterprise Architecture in Action

As part of a proposal, a prospect asked us to provide the 10 most important pieces of advice for an EA team. Wow, I thought, that’s a really good question. And short of being able to do an awful lot of literature research (I am still on this assignment in the Middle East, and my library is at home back in Frankfurt), I just took a shot.

I did not manage to get together 10 guidelines, but have a look at these 4 – and please feel free to fill in with your own experience.

1. Understand the issue you are trying to address
Many EA projects are short of a clear objective - which problem to solve and which stakeholder's needs to address. This results in a lack of sponsorship, inability to measure results and to demonstrate benefits, and a general lack of direction.

The key activity when kicking of or revitalizing an EA effort is to understand the issue the organization needs to address. If it is on the path for massive growth, the organizational structure as well as the organisational assets (including IT) need to be focussed on the value streams driving the growth. In a large organizational transformation, existing assets need to be compartmentalized to enable their reconfiguration.

If it is about cost control, cost drivers need to be identified, areas and mechanisms of cost reduction need to be defined. All these changes are deeply architectural in nature.

Identifying these core objectives allows getting the right stakeholders on board and enlisting their backing by aligning with their needs (well, in the end with their KPIs and incentives). Without them, EA is just another J2EE – a pure technicality without any relevance for the performance of the organization.

2. Organizational Transformation is not an IT issue
While architectural practices and architectural approaches are often driven out of the CIO's organization, they are not a matter of IT. Enterprise Architecture – in the sense of "Architecture of the Enterprise" – is about the way the organization leverages its assets to orchestrate its value chains, how it uses them to build a platform for execution. It is about enabling well-understood segments of variability which link into the core execution infrastructure to create organizational leverage and scale, and to execute on unique value propositions quickly. EA also helps identifying transactional utility services which are opportunities for out- or insourcing - strengthening organizational focus or creating business opportunities.

Building such a platform for execution is a massive organizational transformation initiative. IT can help structuring it; but executing and managing the change is a task of the organization as a whole.

3. Get the right stakeholders on board for the scope you are trying to address
There is no point making architectural decisions if the changes implied are outside the project's circle of influence. Therefore, the project needs to engage stakeholders who have the money, the resources and the influence to make things happen.

The only way of achieving this is to understand the (visible and hidden) objectives of stakeholders in the right power centres of the organization, and to map out how you are going to address their needs. A powerful tool is to align with an existing strategy map, as the objectives there are already agreed between a large number of stakeholders.

4. Communicate, communicate, communicate
Enterprise Architecture has a huge spectrum of stakeholders, most of them outside IT. Engaging them means passing targeted messages through the right – formal and informal – channels. It also means communicating continuously, and providing information both in pull and push mode.
This requires marketing techniques, an area many Enterprise Architects tend not to very well-versed in. So the Marketing and Communications department is their natural partner in these efforts. If there is an internal communications group, great - it will even have the channels and infrastructure. Otherwise, it will have people who can at least help defining how to address the organization.
So, as I mentioned before – feel free to share your advice. I am still 6 topics short from my original target…

Kind Regards from the really, really sunny Middle East
Thomas Obitz

Posted by Thomas Obitz at 10:58 AM | Permalink | Comments (1) | TrackBacks (0)

Posted by Animesh Ghosh, Technical Architect

SOA is a set of Policies, Practices and Architectural patterns; it is not Technology, Product or Standard. These set of Policies, Practices and Architectural patterns must be a part of Governance which is a decision and accountability framework. Governance does not prescribe how to manage an organization on a daily basis. However, it provides a collection of solutions and policies coupled with a method that encourages desirable strategic behavior.
 

It has never been too early or too late for an organization to start SOA Governance, as soon an organization starts its SOA journey, it must be accompanied by a proper Governance mechanism. This journey could be well supported if there is a proper SOA Management and Monitoring infrastructure in place.

The key aspect of SOA is to make business functionality available through a set of well governed, standards based, loosely coupled services and processes, defined in a flexible and agile manner. To successfully achieve this, SOA must be done under proper SOA governance with associated tools in place

Why SOA Management and Monitoring Tool?
 

When an organization progresses with its SOA initiatives it recognizes the challenges that come with the benefits that a successful SOA implementation offers. The Organization realizes that it will need a special set of IT Governance which is SOA Governance. Conventional governance and management does not work because loosely coupled services and their interactions require enforcement of metadata and policy that current tools do not provide. Some of the service-based applications are distributed across different organisations which work in co-operation to perform a certain task.
 
In SOA, an organization is tasked with understanding and controlling a live, dynamic network of interdependent services, one that evolves quickly and includes application components beyond the control of the IT staff of a particular organisation. Governing this de-centralized production system is critical to success with SOA and requires a specialised tool. A SOA Management and Monitoring Tool can provide an insight view of the SOA service infrastructure to the Business and IT team, giving more relevant information for decision making and accordingly the team can manipulate the services.

Figure 1 below shows how a tool becomes an integral part of an organisation’s SOA journey.

 

Figure 1

How to select a SOA Management and Monitoring Tool?

One of the main aspects of a successful SOA is the careful implementation of a SOA Management and Monitoring infrastructure. As SOA Governance is about decision and accountability framework, while selecting a tool we need to understand how well a particular tool might fit into the existing framework and help to manage and monitor SOA infrastructure. SOA is an incremental process. ‘Big Bang’ approach really does not work here. An organization needs to select a tool that can support it at any level of SOA maturity and during the transition to the next level.

The ultimate aim here is to satisfy customer’s needs and business is the main customers over here. A tool must provide a meaningful business view from where an non-IT (i.e. business) will be able to get what he needs to make business decision which is directly linked to organizational Goal and Strategy.
 

Tools from mega vendors like IBM, Microsoft, HP, Oracle etc. each of them tried to address different aspects of SOA Governance and Management challenges in their own way using their own set of technologies. However, the most crucial aspects to consider when choosing a SOA Management and Monitoring tools are:

• Policy-based approach (Business)
  
• Service network monitoring (Technology)
  
• Service and infrastructure discovery (Technology)
  
• Service level management (Business)
  
• Exception management (Business)
  
• Policy enforcement (Business)
  

Organizational aspects are more important than Technology aspects while selecting a SOA Management and Monitoring tool which must facilitate the comprehensive SOA Governance of the organization.

Figure 2 below summarises what to consider while selection a SOA Management and Monitoring tool.

 

Figure 2

Tools from each of the vendor are good in certain angle but deciding the right tool for an organization requires careful consideration of the needs and the relative strengths of each product. There are several tools from the major vendors and here is what my personal view about them.

o    HP OpenView can provide end-to-end monitoring capability for virtually every kind of application in this world. HP Systinet focuses on comprehensive SOA Governance and Management. You got to use them together.
o    IBM Tivoli Composite Application Management for SOA emphasizes core web services management and integration with the Tivoli Monitoring framework. This tool is matured enough to count on.
o    The only tool focusing extensively on organizational governance aspects. AmberPoint focuses on managing the runtime aspects of SOA Applications and helps to manage performance with service-level objectives.
o    Actional focuses more on service monitoring and it provides a comprehensive end-to-end view of activity and performance of executing processes.
o    Oracle is a leader in Forrester's SOA Lifecycle Management Wave, via acquisition of BEA, providing comprehensive support for governing the entire SOA ecosystem and out-of-the-box support for capturing and measuring your SOA investment.

Posted by Guest Author at 8:34 PM | Permalink | Comments (1) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Swades and the lessons it held for Architects about giving back in the form of teaching budding architects, publishing papers etc.

The 300 Spartans (Year of Release: 1962; Director: Rudolph Mate; Our Architect: King Leonidas, played by Richard Egan; Architect's Character: The Greek king of Sparta who is up against a stronger Persian army)

‘The 300 Spartans’ depicts the invasion of Greece by the Persian army and the role of King Leonidas, the king of Sparta, known for its proud, bold and courageous army. The story deals with a number of issues – the role of the senate, the mammoth scale of problem at hand and the values of a team, in this case of a state.

The legend is that King Leonidas, prohibited to use his army to fight against the Persians by his own Senate members, decides to take on the swarm of Persian army with 300 of his body guards. His force not only holds the Persian army at bay in a long drawn battle but also ignites the values of the rest of the Greeks who decide to launch an all out war against the Persians. This movie was remade in 2006 under the name ‘300’.

 The lessons that this movie offers for architects are:
•    Doing the right thing – aligned with our own personal and moral values.
•    Courage under fire
•    Setting an example to ignite other minds.
•    Persistence
•    Looking for alternatives
•    Attitude!

For this movie too, I will skip talking about any specific scenes because it makes its point through the whole storyboard. There are a lot of lessons that we, as architects, can pick up from this movie. The most important one being – develop the right attitude and use it! The second most important thought that this movie provokes is to introspect ourselves to see what are we made of? What are our values and how do we prioritize them.

Values are something that take the form of our signature in all our work. You can tell from the work of an architect that he places higher premium on technology than on business, or if he confronts issues vs. sweeping them under the carpet.  Values form the torch light which show us the way when all other light is swept away. They can push us to do the right thing and doing the things right.

Posted by Guest Author at 9:40 AM | Permalink | Comments (0) | TrackBacks (0)

As I sit down to blog for the first time on the Enterprise Architecture blogs, a very fundamental question crosses my mind.  That is how do architects speak, or communicate in general.

 A very common occurance is to use a lot of buzzwords.  I once encountered an architect who said "issue A and issue B are orthagonal".  He meant A and B are independent of each other.  Architecture patterns too - be they singletons or facades - can be confusing explanations to IT management and customers.

The main issue I wish to raise is that does our language need to be so threatening to outsiders.  No wonder many times architects are described as out of touch or too abstract.

My experience is that messages to people outside the architecture community need to be in simple language.  Business executives who often are sponsors of IT work, and hence of architecture projects, business operations managers, IT project managers are all interested in understanding the recommended course of action and the rationale for it.

While the rigour of architecture formulations is a necessity, very often architects use complex language to impress each other.  Over a long period of enterprise architecture engagements, I have settled on simple and clear working and final deliverables that do not require translation before being tabled to the stakeholders

I will like to know your experience.  What parts of the architecture speak, in your opiniion, are complex by necessity and need the relevant rigorous terminology?  Do you or people you work with use long words just to impress each other?  Or, as in the words of my above mentioned architect friend, need and practice are othagonal to each other?

See you around.

Rajeev Arora

 Melbourne. Australia

Posted by Rajeev Arora at 3:05 AM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Padosan and the lessons it held for Architects about observation, analyzing the non-obvious, taking care of your team, knowing your priorities etc.

Swades (Year of Release: 2004; Director: Ashutosh Gowarikar; Our Architect: Mohan Bhargav, played by Shahrukh Khan; Architect's Character: A Music Director by profession, US-based research scientist with NASA, of Indian origin).

‘Swades’ is a story of Mohan Bhargav, a research scientist with NASA. He has Indian origin but is settled in the US with a nice job and comforts of life. He makes a trip to India to see his grandmother when leads him to a village. During this trip, he gets a firsthand experience of life in rural India and how far behind they have been left from the ‘progress’ made by towns of the world.

As a first project, Mohan helps a bunch of villagers set up an electricity generating unit. Subsequently, he decides to move back to India for good and dedicate his life for the advancement of rural India.

There are three important lessons that this movie can teach architects:
•    Giveback
•    Giveback
•    Giveback

I will refrain from going into the specifics of a few scenes for this movie, as the message is spread across the whole movie in bits and pieces.

As architects, we often forget to take a breather and give something back to our community, to our industry which has given us the fabulous opportunity to work and make living doing the stuff that we love enough to do for free.

At the end of every year, an architect should measure his/her success by the number of things he/she has given back in that year. The 'giveback' can take form of a class that you taught to budding architects, a paper that you published based on your experience to spread your knowledge or a novel item that you invented to aid the industry.

Posted by Guest Author at 12:45 PM | Permalink | Comments (0) | TrackBacks (0)

- Mohan Babu K (cross posted from the Managing Offshore IT blog)

In my previous post, I talked about the extending role of Enterprise Architects at services firms into Marchitects. This ‘selling’ of architecture services is no different from what our peers in client organizations undertake too.

Enterprise Architects, many of whom report into a CIO/CTO organization are also under continual pressure to ensure that the organization derives an optimal ROI from their IT investments, which means they need to ‘sell’ the value of robust, scalable architecture, planning and roadmaps to their stakeholders, some of whom may be focused on the tactical: ensuring that the quarterly targets are met, budgets balanced and operational challenges addressed. Even the ‘strategic’ focus may sometime involve reacting to external trends (read between the lines: it is the economy, slowdown etc)

But back to the challenge of selling that Enterprise Architects at service firms face:

• Thinking beyond revenue and dollars: Most service firms aspire to move up the proverbial ‘Value Chain.’ And when it comes to technology services, what better value chain than consulting with client CxOs on their Enterprise Architecture? However, this ‘move up value chain’ is not as simple, or even sexy as it sounds. Why? Because sales teams at services firms are geared towards (and rewarded for) ‘downstream’ and ‘incremental revenue.’ The challenge is that when consultants work with clients on their EA strategies and roadmaps, they shouldn’t - and generally don’t - have downstream-dollar-signs in their eyes…. which doesn’t always please internal sales teams. [footnote: taking this high-road is not always practical since reward (and bonus) structures for individuals, including architects at service firms are geared towards meeting unit, group and organizational numbers.] 
• Being unbiased while recommending solutions: Another challenge consultants, especially from larger services firms face is while recommending solutions and technology options to clients. Architecture consultants from a product vendor organization may have their account teams tacitly leaning on them. The reason is not hard to find: most service firms have their proprietary solutions, frameworks and toolkits for myriad technologies. Consulting organizations make considerable investments in developing such solutions and the ROI can be derived only when sold/deployed by clients. There are times when these toolkits and products may be an ideal fit for a client need; but not always. Consulting Enterprise Architects need to be unbiased and be willing to push back their Account management teams when need arises. [Again, taking the high-road may come at a personal cost: internal bonuses and incentives]

Clients have an opportunity (and perhaps responsibility) to ensure that the high-end consultants they engage continually provide unbiased inputs. In a sense, the challenge faced by consulting Enterprise Architects is an opportunity to you, the client. You can efficiently leverage their ideation, selling, persuasion and presentation skills to help your internal Enterprise Architects and CXOs sell the ideas and strategies to your businesses and stakeholders. By doing so, you let consultants gain the privilege of being trusted advisors, which in some cases may lead to additional downstream and business for their firms.

Posted by Guest Author at 11:27 AM | Permalink | Comments (0) | TrackBacks (0)

Gartner predicts that by 2009, a service-oriented eco-system will mature and provide the foundation for a massive wave of business process innovation. Most organizations today have some level if interest in SOA as a 'future' strategy. However, an early barrier to the adoption of SOA is the appreciation of the difference that SOA can make to the organization. Maturity of SOA adoption  across the globe has not yet reached the level that can provide measurable benchmark for predictable ROI commitment. Hence, the qualitative appreciation of the SOA values can probably play a critical role in the accelerating the momentum of the SOA initiatives. Range of opportunities that SOA brings to table allow organizations to exploit multi-dimensional benefits  from SOA. SOA can make lot of difference to the organization if it is adopted as a mainstream Business-IT framework.

Consistent and high-quality Service experience
SOA enforces standardization of service behavior which will mean that consumers of the services will experience high degree of consistency and quality throughout the life-cycle of the service delivery. This is particularly important because service experience is a key component of the ‘service orientation’. When services are being designed and developed, service behavior becomes an integration part of the considerations so that when services are deployed, the experience it creates with service consumer in terms of service engagement, service usage and service support, that makes lot of difference to consumer community.
More meaningful Business - IT mapping
Traditionally, I always felt that transition from business requirements to technical architecture has been a challenge in the industry due to lack of practical frameworks that can be used as transition model. With SOA, now we have service architecture sitting in between business functional design and technical design. This allows business functional maps to be easily configured and mapped to IT capabilities (typically using BPM wireframe) without creating hard-wiring between the two. This way in my view, whole service modeling and service architecture exercise brings Business and IT together where each has a critical role to play to make the SOA happen. This becomes partnering model between business and IT as opposed to traditional ‘handover’ model where business disengages itself after certain stage expecting IT to take over.
Shared view between Business and IT
Further to previous point, Service architecture acts as a common language / platform / view between business and IT and thus enables more meaningful and collaborative engagement between the two. Typically the gap between business and IT in terms of delivery model as well as common vocabulary has been a concern for most of the enterprises. Now Business and IT can talk the language of services that will make sense to both communities.
Service Level driven focus
Service level focus, in my view is a very essential part of the ‘service-orientation’ that also plays important role in the ‘service experience’ that we talked of before. In an SOA driven environment, service levels are governed to cater to stringent business performance metrics in direct fashion and hence entire monitoring, reporting, alignment, support and continuous improvement efforts are focused around the service level performance of the services. This changes the tradition model of ‘managed by exception’ to ‘managed for excellence’ which hopefully will change the level of accountability and ownership IT teams specifically take today for the business outcomes.
Separation of logical capabilities to provide simpler and cleaner architecture
Service architecture provides ability to consolidation and rationalize the business / IT capabilities in optimized fashion that have similar behavior, anatomy and operations. This allows more cohesive and efficient interactions/collaborations across capabilities in various logical layers (by design rather than by accident) to deliver final business outcomes. In principles, software architecture had the ‘logically’ separated layers always but with service architecture, now it is much easier to separate out the logical layers at execution level as well.
Easier Change Management
Changes ( of all sorts, technology change, business change, regulatory changes, IT vendor change, IT in-house staff change) are here to stay in the industry, at least for good number of years in my view. Through various core principles like decoupling, virtualization, meta modeling etc in SOA, it will make the life easier to change different elements of the solution without too much pain or expense. Change management is adopted as a mainstream focus for service management and hence we can expect more discipline in maintaining the software solutions.
Hide technical complexities of service implementation
Service architecture allows diversity in service implementation (through mash-ups, service virtualization etc.) to make use of new technologies while enforce standardized service interface to shield the consumers from complexity of service integration and implementation. As I see, industry is far from standardizing on a single technology platform and as we move further in future, more and more technology advancements will put the challenge to technology standardization. If we accept that fact, service architecture paradigm will allow enterprises to leverage new technologies in more flexible, open and easy manner.
Quicker and simpler solution composition
Making the software solution composition (highly productive, cost effective by reuse and ability to innovate solution patterns etc.) and development life-cycle (allows develop, testing and deployment done at service level where service being the modules of development and not the components) quicker and simpler is another difference SOA adoption can bring into the organizational DNA. This has long lasting implications, much wider than what we might think. Service architecture based development practice will bring innovation to transition typical ‘build’ intensive solutioning methodology to ‘composition’ intensive methodologies. This will not only allow the need of having large ‘coding’ teams with intense technology knowledge to be shifted to more ‘solution composition’ teams that may not so much technology intensive knowledge requirements. That way, today software development talent profiles are already upgrading themselves into new roles which I think is a positive change.
Business Scalability
Ability to support (and even ignite) the business growth (more services, more users, more geographies, more partners) through accelerated scalability, global integration capability and easy service on-boarding infrastructure is definitely a great win for business community. Business scale is not just in terms of doing more of the same but actually lot more of ‘doing different things’ for which time to market is a key differentiator. Service fabric of the business-IT architecture allows easier composition of the solution as we learnt in previous points and further to that, it ensure that when business goes out for scaling in terms of functionality, geographies, value chain expansion etc, the SOA enabled business-IT architecture acts as a enabler to support the change.

In general, I could say that SOA has lot in store to transform the organization but probably it is the seriousness that industry has to get to make it happen. I'm very confident that it will happen. What do you think?

Posted by Rakesh Mishra at 9:59 AM | Permalink | Comments (0) | TrackBacks (0)

In the last 2 blog posts, I talked about use of XML Appliances to turbocharge your SOA infrastructure. In this blog, I intend to provide some numbers provided by Intel. Most other vendors do not seem to have these numbers in a public document.  The features described here are available from many different vendors, and the other products in the space are equally good, with comparable performance numbers.

Intel's appliance is not actually an appliance but a product called SOAExpressWay. It runs on standard Linux servers, providing the "benefits of having an appliance, with the flexibility of a server, while using commodity hardware".   

 The benchmark numbers are impressive, and are for a dual CPU Intel Box. I wish the benchmarks used Java 1.5, which is approved in many enterprises rather than Java 1.6, which is not. But I do not think the numbers will be dramatically different.  

 Want to protect your SOA infrastructure from being flooded by badly written XML that does not conform to your schema? This could be an external denial of service attack, or more likely an error at the XML producer end. With SOA and agile development, there is the advantage of incremental development, but it is coupled with the risk of error prone code getting into your production or performance/staging environment.  The Intel SOAExpressway can validate XML to a schema at the rate of 507 MB/second, on a dual CPU box.

Want to validate the data that has come in using simple XSLT based rules? The Intel SOAExpressway provides XSLT processing at very high speeds. For example, specific fields could have valid ranges, or be constrained based on values of other fields.

An interesting feature of the SOAExpressway architecture, that it is not a pure appliance- non-XSLT based validations written in Java or C++  can also therefore be done on the XML data. As pointed out in this  excellent presentation on parleys.com(see slide #20,21) ,  there is always something that is very difficult, if not impossible to do in XML.

Want to convert about 1 GB of flat file into XML? It should take about 30 minutes or less with the SOAExpressway running on a dual CPU Intel Linux server. A past engagement showed a data volume of 50 MB per hour exchanged with an external application service provider. It would have been very convenient to use an appliance to validate, transform and import/export data using a product like the Intel SOA Expressway. The flat file to XML conversion is comparatively slower.

XML to XML conversions run a lot faster. The benchmark paper mentioned earlier, shows XML to XML conversions running at between: 500 KB per second to 41 MB per second. This is on a dual CPU box. This is not "wirespeed" as most appliance vendors hype, but it is enough to meet the needs of  many enterprise or even consumer facing enterprise portal needs. For example, consider a WML page of 4 KB on a cellphone, which is refreshed every 60 seconds. Assuming a transformation rate of 20 MB per second, a dual CPU server could support around 30,000 users.

XPath execution speeds in the  benchmark paper ranged from 400,000 to 1.5 million expressions per second. Using XPath to perform rule based validation, is thus very scalable using the Intel SOA Expressway. Incoming XML document can be validated for consistency, such as "To-date" being greater than from date.

Why not use XALAN instead? The manageability features of the SOAExpressway including basics such as SNMP Trap creation, Email notification, as well as the more advanced features such as  application level end-point support  and  Scriptable management using CLI are critical in an enterprise environment. 

A common problem in many SOA Projects is creating a "sub-set" XML document, from a given XML document. For example: The XML provided to you has 250 fields, but you need only 10 of them, in your application. A standard pattern is to read the large XML document, parse it to discover the 10 needed elements. The memory consumed in this parsing operation, can be large, causing frequent garbage collections.  Performing this operation on Intel SOAExpressway should be a lot faster than in the application server.  Moreover, you are  performing the transformation on a server that is comparatively cheaper. A fully loaded dual J2EE  Portal Server can easily cost  upwards of $100,000 per fully loaded server. In one portal project, about 95% of the portlets, called webservices on the backend, and transformed the XML so obtained, to generate the HTML markup. The  XML transformation load could be a large fraction of the CPU use on your expensive portal server.

In a given project, thinking about using a XML appliance may be difficult, but if XML Transformation and validation are provided as standard services, then this technology can percolate into the mainstream of your enterprise.

Posted by Kevin Apte at 6:39 PM | Permalink | Comments (5) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Remember the Titans and the lessons it held for Architects about leadership, change, how to get people from diverse backgrounds to work together etc.

Padosan (Year of Release: 1968; Director: Jyoti Swaroop; Our Architect: Guru, played by Kishore Kumar; Architect's Character: A Music Director by profession, Guru always has a solution for all problems and never lacks innovation)

This is one of my favorite movies. It is witty, sharp and outrageously comic. Our architect is the character of Guru (Vidyapathi) played by the legendary Kishore Kumar. Guru has a flock of 4 friends that he is really close to and is always available to them in the role of an advisor, a psychiatrist and above all a friend. He has solution for almost every problem that you can throw at him. Most of his solution look awkward, but they all work beautifully! The outline of this movie is how Guru helps his friend, Bhola (played by Sunil Dutt), who has no knowledge of music, to capture the heart of a dame, Bindu (played by Saira Banu), who is obsessed with music.

There are a lot of things that an architect can learn from this movie. A few worth mentioning are:
•    Never say die!
•    Keen Observation
•    Analyze the non-obvious
•    Take care of your team, your mentees, be there for them.
•    Know your priorities

Scenes to watch for:
1.    There is a scene in the middle of the movie, where the whole gang tries to spy on Bindu and her music teacher – Master Pillai (played by Mehmood). While spying, most of the other members of the team are obsessed by how beautiful Bindu looks and some are totally angry with Master Pillai for his bold movies. While all this is happening around him, Guru, using his keen observation skill analyzes that in reality, Bindu has no liking for the teacher per se, instead, she is fascinated by his musical talent and respects him for that. This single observation shapes up the remainder of the movie and becomes the key instrument in getting Bhola, his life’s love.

Although it sounds very simple, but keen observation is a very rare skill. Unfortunately, it is also one of those skills that you cannot pick up in a class. You need to practice it by opening your mind and trying to look beyond the obvious. The architects who master this skill are automatically promoted to a different league than their competition. They have long lists of satisfied clients and are up to their neck with repeat business.

2.    At one point during the movie, when Bhola loses faith in Guru’s strategy and approach, he grows dull and erratic. In this scene, Guru cheers him up by pointing out the silver lining and giving him a projection of what future could hold. At the same time, he also addresses his immediate concern by justifying his approach and elaborating on why he is doing things the way he is doing it.

It is a very common problem with us as Architects. We usually get carried away with the details of the technology and assume that our team and the people sitting across the table understand the reasons and rationale, right? Wrong! It is quite important for you as an architect to explain your decisions to the people around you – in the form of architectural decisions documentation or one-on-one discussions - whatever works. The flip side of this aspect is that if your team does not understand why a decision has been made, they will not be able to sell it on your behalf to others. In fact, it can also happen that they come back from meeting convinced that the decision that you have made is wrong. And the problem keeps on snowballing …

3.    In general, throughout the movie you will notice that our architect never gives up. He is always on the lookout for alternatives, for other things that may click … for a plan B. During the first half of the movie, upon learning of Bindu’s fascination of music, Guru tries to teach Bhola the fine art of music.  After failing miserably at that, he comes to terms with the fact this approach is not going to work and let’s go of the approach. While he is pondering over what to do next, his mind picks up the faint sound of a radio playing at a distance. One thing leads to another and not a long time after, he decides to work with Bhola as his playback singer. A pure, master stroke of genius!

This scene can teach us the value of keeping our eyes, ears and mind open. The next big idea can come from anywhere and at any time. There are lots of corollaries available outside the technology world which can give us insights into how to tackle the most complex of IT issues. Another important lesson in this scene is to understand and appreciate different talents available in your team and come up with ingenious ways on how to put them to best use. You have dead weights in your team only because you have given up on figuring out how best to use the skills available.

Posted by Guest Author at 9:22 AM | Permalink | Comments (3) | TrackBacks (0)

Well as with any other conference, the excitement slowly goes down as number of days pass by.  There were fewer participants for Day 3 and Day 4, with hardly authors seen around for presenting their work.  Keynotes in my view should throw some light on to new research directions, trends and innovation opportunities.  Keynote themes at SCC 2008 on three days also were pointing a direction.

Adaptive service based for developing future software, game changing cloud computing and its complementaries with SOA were the themes that were discussed during the keynotes.   This has shown that research community and academia is excited about the cloud computing.  Industry has already seen success of cloud computing with most notable one being Amazon’s EC2 and S3.  The debate was how research community would need to fuel innovation for cloud computing. The explosive growth in social networking, mobile platforms and collaboration platforms will see more and more innovations in near future.

Clearly as it could be noticed based on all the papers presented, the service computing research community is heading towards developing platforms for large scale development.  By large scale development what I meant was development that not localized but distributed across many locations.

Also, I feel worth mentioning here is an intresting poster stuck near the registration desk, it talked about a mashup application.  An application which could help in monitoring and possibly predicting the effect of wild fire.  It took the information provided by google earth API's and weather information service. It is so interesting to see so many valuable innovation and possiblities through mashups.

Posted by Naveen Kulkarni at 10:40 AM | Permalink | Comments (0) | TrackBacks (0)

- Mohan Babu K (cross posted from the Managing Offshore IT blog)

While reading Andrew Manning’s blog entry on “Enterprise Architects: Time for more job titles?”  I began thinking about a barbeque I attended at a friend's place few weeks ago where colleagues and peers had gathered. It was interesting to observe that folks who had gathered were finding it hard to pick on neutral topics beyond the day’s weather and the difficulty in maintaining the lawn, using the host’s backyard as a case-in-point. It was not hard to see why.  A few were from the ‘sales’ side of our business – account managers, engagement leaders and the like – and others from the consulting side - IT architects and consultants. And not surprisingly, it was the few Marchitectects in our midstwho were trying to find an icebreaker.

Going back to Andrew’s list, I guess, one title, I would add is Enterprise Marchitects: folks at service firms who act as a bridge between sales and consulting. The “Enterprise Architects” at service firms - many of whom are also Marchitects -  have a distinct role to play in the industry. The role also comes with its share of challenges for obvious reasons:

• Consulting Architects are generally sought ought in the industry and are well compensated, because of which their services also command premium/higher billing rates. From a software services context, it also means that Architects can add to a significant ‘cost’ component of a typical project. Cognizant of client’s cost constraints, the some Account Managers are more comfortable underselling the need for an architect to ensure a bigger pie of rest of the project rather than translate ‘cost’ to demonstrate ‘value.’ This means the architect, who is already under pressure to be continually ‘billable’ also has to juggle the hat of a Marchitect
• Architects also need to accept the fact that though they bring a specialized/niche skill to the table, they are still considered as ‘resources,’  both to a firm’s own sales folks and of course to client’s FTEs and program stakeholders who naturally look at external consultants as hired-guns.
• Another Marchitecture dimension is to juggle the buzz from internal and external spin doctors. Those of us who have been in the industry long enough know what I mean by spin doctors: folks who can take archaic sounding acronyms coined by industry analysts, visualize a few possible ‘scenarios’ and ‘solutions’ and start preaching it to clients, all with the conviction of a convert.

Enterprise Architects with service firms juggle the above challenges, along with their day-jobs of helping clients architect robust, scalable technology and business solutions. Which brings us back to where I started: the delicate balance between Architecting business and technology solutions - which architects are skilled at – and the business of architecting technology solutions (read ‘selling’ architecture as a service) which is a skill Architects try to acquire. Now, this yin-yang has another dimension to it: measuring the ‘value’ that a consulting Enterprise Architect/Marchitect brings to the table. …

I will continue the line of thinking in my next post

Posted by Guest Author at 11:25 AM | Permalink | Comments (0) | TrackBacks (0)

It was the day of presenting research and industry papers.  There were many interesting topics that caught my attention; but I had the choice of attending only a few as they were mostly running in parallel breakout sessions.  I certainly did not want to miss the sessions that were discussing - management of distributed collaborative centers for executing work requests, change request scheduling, using domain knowledge for service integration, establishing service model from business model and variation oriented engineering... 

As I looked at the program schedule and started marking the topics to attend, it became evident that I was still loomed with yesterday's discussion.  My inquisitiveness - to find answers for those questions had made we choose the above mentioned topics.  Interestingly most of these topics were presented by researchers from IBM.  Most of the discussion was around the capabilities of execution centers, managing resources, an important conclusion that I could draw was that - It is necessary to model work allocations based on execution centers rather than on task and resources.  The resources should however be considered as the capability of execution center.  Further from other session researchers explained the importance change management, knowledge, service modeling and variation based approaches for Service Engineering.  There were few approaches proposed for which I would need more detailed reading.

After the initial excitement about Service Engineering, post lunch it was time for the topic which I have been looking for - Architecture for service based computing.  This tutorial proposed an 'Enterprise Service Architecture' (ESA) and gave the background and stressed on the fact of why this was necessary.  This explored the use of competence theory for answering few important questions that researchers perceived very essential. However, most interesting part of the tutorial was when the authors reviewed various frameworks that could be the basis of ESA.  Few of these frameworks that I remember were Porter's Value chain model, Business motivation model, Strategy maps, i*, and few more.  The tutorial was concluded by highlighting few gaps and setting few more motivations.  This being my area of interest, I feel there is lot research that needs to be put in both from formalizing it and finding ways to apply to real life situations.

The day ended with a simple and quite banquet, a regular tradition at any conference....

Posted by Naveen Kulkarni at 11:10 AM | Permalink | Comments (1) | TrackBacks (0)

I had to travel around the world to attend a conference.  Well it was at Hawaii, so travel really didn't matter much.  It was Day 1 of IEEE SCC 2008 conference, this day was dedicated to some interesting workshops like Electronic service marketing, Web X.0, WS composition and adaptation, Scientific workflows.  I had to present three papers at Service and Process Oriented Engineering Workshop (SOPOSE) (you can find the program here). 

This workshop followed a unique model of each paper having a discussant.  This, in fact, kicked off some interesting discussions.  One which interested me was around the topic of goal mapping to existing services.  The author had presented an approach (BGSC Graph) to match services closely to requirement while discovering them.  However, my understanding was that author had made an assumption of having a service portfolio but hadn't considered the origin of service.  It has been our experience that service created within organizations today still lack the rigor of having gone through the top down approach (starting with what the business wants).  This would mean it would be difficult for breaking up the business goals and matching with objectives with which services were created.  However, on another note, I feel this would be useful if the services are being sourced from partners. Today we have Amazons and SAPs offering out of the box services and this method (BGSC Graph) can help in evaluating them.
 
There were a few other discussions around verification of correctness of contracts, an architectural model for SOA and modeling virtual enterprises.  Interestingly though not in earlier program, there was a key note from Dr. Banavar, Director of IBM India research lab.  Following the key note discussion loomed around what would the future and according to Dr. Banavar, it was Services Engineering.  "Disciplined Service Engineering can help the world economies to systematize service development, and focus on service innovation" to quote from the presentation was the compelling factor and the necessity for the services community to investigate.  He brought out two immediate areas to make service engineering possible.  Firstly, was similar to industrialization ie., large scale development using distributed collaboration across the world and secondly the technology aspect - a new way called variation-oriented engineering.  The discussion ended with the note that we the research community in services computing have to raise to address the challenges of the future, which will come as Services Engineering.

Will continute to post some interesting discussion at conference...

Posted by Naveen Kulkarni at 12:47 PM | Permalink | Comments (0) | TrackBacks (0)

As IT is always full of jargons, SOA is no exception.  One of the most commonly used terminology in SOA world is the term ‘Reference Architecture’. However, there are several places where people seem to mix-up the term ‘Reference Architecture’ with ‘Reference Model’ which puzzled me initially to a large extent. Since then I have been trying to understand the fundamental difference between these two and trying to address the following questions that kept coming up in my mind –
-          Are they same?
-          What is the relationship between the two
-          Do  they co-exist
-          How does one define them and what are the different characteristics

 

So what’s the ‘Reference Model’

•          SOA Reference Model (SOA-RM) is a framework which captures the various capabilities/patterns (e.g. Multi Channel, Process Automation) required to effectively implement a service based information technology platform for achieving a specific business function or a set of business functions
•          These capabilities are grouped in 2 main categories
•          Functional – The capabilities in this category help the services meet a specific business function or a set of business functions
•          Non-functional – The capabilities in this category help the services meet the business functionality within the defined contracts
•          SOA-RM is not directly tied to any technology, standards or concrete implementations. It provides a common understanding that can be used across different implementations
•          Is superset of Reference Architecture: Reference Architecture is derived from Reference Model
•          Highest level of abstraction

 

What’s the ‘Reference Architecture’
-          It defines a consistent vision of SOA throughout the enterprise/business Unit and  supplies the context (for identified patterns) for imposing best practices on development and deployment of SOA
-          It offers an architectural framework for planning SOA-based projects that maximize interoperability and reuse across the enterprise or business unit
-          It represents IT’s architectural alignment (through selection of technology stack) with the business objectives for SOA. In the process, this helps the business case associated with the SOA initiative, including infrastructure requirements (technology, process, etc) and investment priorities.
-          Guided by Reference Model
-          Drives towards concrete Technology Architecture. Considers Protocol, Standards, Specifications etc. Accounts for Business and Technical Requirements, IT/Business Goals

 

Lets take a real life example, to ensure the difference is clear enough. Reference model for a vehicle would be:
·         Need for a vehicle which would help to move from one place to another in a reasonably faster way
·         Must carry people in sitting position
·         Should have a mechanism to control the speed/direction
·         Either automatic or manual manoeuvre
·         May have cruise control

Now taking this to next level i.e. A Reference Architecture. Eventually you might end up having different Reference Architecture depending on the need of the final Vehicle. In this case, the Reference Architecture for a car would address the following
·         Must have seat to ‘carry people’
·         Must have engine ‘for speed’
·         Must have steering wheel to ‘control the direction’
·         Must have wheels ‘for movement’
·         Must be automatic
·         No need to have boots
·         No cruise control

Now concrete implementation would have
·         How many seat car should have – 2 seats or 4 seats or more
·         Engine capacity 1.2ltr or 2.0ltr or more
·         Size of the steering wheel
·         Number of Wheels – 4 or 6 or more

In terms of decreasing level of abstraction: Reference Model --> Reference Architecture (can be many RA for a RM) --> Concrete Implementations

Posted by Shubhankar Sumar at 7:42 PM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie Lagaan and the lessons it held for Architects about selling ideas, negotiations, leading change etc.

‘Remember the Titans’ (Year of Release: 2000; Director: Boaz Yakin; Our Architect: Coach Boone, played by Denzel Washington; Architect's Character: Chief Coach of the first mixed race football team) is set against the time of segregation. Then the Government abolished segregated schools and gave the right to all students to enroll in any school. The movie focuses on one such school - T C Williams High School in Virginia which has been educating white students but has now opened up to black students too. There is an atmosphere of tension and apprehension on all sides. In the midst of all this turmoil, Coach Boone lands up as the head coach of the school’s new football team.

Even in the game of football, there is a lot of resistance from both the sides to come together. Coach Boone leads the team to look beyond the color of their skin and teaches them to function as one integrated unit. This movie is based on a true story and the team that the coach put together went all the way to win the high school championship in its first year.

The lessons that an architect can learn from this movie are:
•    Leadership Qualities
•    Acting as Change Agents
•    How to get people of diverse values & backgrounds to come together as a team
•    Maturity to appreciate when usual rules do not apply
•    Improvisation

Scenes to watch for:
1. There is a scene during the initial rounds of practice when a black team mate is confronted by the captain, who happens to be white, on how he is not playing for the team. The captain goes on to describe this player as a waste of God gifted talent and criticizes his attitude. To this, the black player replies – “Attitude reflects the leadership, Captain.” He further substantiates his statement by pointing out how some of the white players are not playing the game in the correct spirit, right under the captain’s nose and how that does not bother him.

This is one big, big take away from this movie. In our world too, attitude of the team that we are working with reflects the attitude and approach of the leader. This particular scene teaches us the value of being fair, treating every team member with respect and impartially. It also emphasizes the importance of seeking feedback from the juniors who work with you directly. This can happen informally, over a cup of coffee or a beer. What differentiates a good architect from a great architect is the latter’s ability to be open to criticism and adaptability to change.

2. After the end of a very trying training camp which lasts for a few weeks, Coach Boone congratulates the selected team by saying – “I am not going to talk to you about winning or losing. You are all winners in my book already. Because you did not kill each other at the camp”.

The very simple gesture of appreciation can go a long way in boosting your team’s morale. And yet, we don’t see it happening as often as it should. This is doubly true for high risk, high stake projects because everyone gets so engrossed in the day to day work that there is hardly any time for appreciation. Regardless of the nature and complexity of the project that you work on, do remember that you are working with people; people, who are not machines. Appreciation is a nice gesture that should be displayed whenever the opportunity arises. For complex projects you should list it as a to-do item in your task list to look for opportunities for appreciation the same way you find out time for reviews.

3. In the concluding scene of the movie, there is a dialogue by one of the coach’s daughters – “People say that it can't work - black, white. Here we make it work every day. We still have our disagreements, of course, but before we reach for hate, always, always, we remember the Titans.” That, kind of, sums it all up!

Gives you a true picture of how team with diverse backgrounds can come together and achieve wonders under the architect’s leadership. Need I say more?

Posted by Guest Author at 7:58 AM | Permalink | Comments (0) | TrackBacks (0)

One of the key benefits of BPM solution is that it provides insights into the performance of business processes through Business Activity Monitoring (BAM), and enables process analysts to identify impediments & bottlenecks in performance of the business processes. While that sounds very exciting, getting pointers to the real bottlenecks is not easy. ......

For any meaningful process performance analysis, it’s imperative that the statics gathered through BAM have business significance. For this it is very important that business relevant high impact KPIs are defined during process design. ...

 

To define business relevant KPIs following methodology can be adopted

-         Define key objectives for BPM initiative, such as enhance customer responsiveness, improve quality, expand market share, reduce product design cost etc.

-         Translate the objectives into quantifiable goals, e.g. reduce turnaround time for customer on-boarding from 5 days to 2 days, increase new customer contacts in southern region to 45 per week, …

-         Having defined quantifiable goals for BPM initiative next step would be to identify candidate processes for implementation and categorize these processes into critical process, value add process, support process etc. Categorizing processes into these broad categories helps define goals for the process categories (and thus for each process), e.g. value add process have maximum potential for enhancing market penetration, increase revenue etc, while support processes greatly impact customer satisfaction.

-         Once processes are categorized and process goals are defined, business analysts would analyze each process and from the process goals derive matrices and KPIs for all critical activities

-         Next step is to set milestones and targets for improvements in these KPI measures

 

 

Defining KPIs derived from business goals helps analyze performance of the business processes and facilitates identifying real impediments in achieving the performance goals, which helps redesign the business processes and improve business performance

 

Posted by Dhiren Mehta at 9:33 PM | Permalink | Comments (0) | TrackBacks (0)

Gartner recently published their June 2008 Magic Quadrant for Enterprise Architecture (EA) tools. (See http://www.gartner.com/DisplayDocument?id=697707&ref=g_sitelink (registration required); or a free version at http://www.troux.com/company/news/pressrelease.asp?pr=080618_gartnermq_pr.xml).

A couple of things sprang to mind as I skimmed through the report:

Tools are rarely the main reason for unsuccessful EA activities. There's the commonly quoted phrase "a fool with a tool is still a fool" (and can add "a fool with a tool can do more damage more quickly").

The same is true for the Gartner Magic Quadrants. As a tool they can be misused, intentionally or not. The report has a specific scope, focussing on the modelling and repository aspects of the tools (and to some extent publication) as well as supplier capabilities. It's easy to be lulled into thinking that tool X is better than tool Y (even if it is only at a high level). But this ignores a number of other dimensions such as: the tool's ability to support different levels of organisational capability; how likely it is to be adopted by different user communities; how well it supports 'getting stuff used'...
 
Personally, I like the Gartner 'Magic Quadrants' . They're handy for showing people an overview of the main players (selected by Gartner, and less useful if there is something you want to promote that doesn't rank highly). The quadrants have a reassuring, semi-quantitative feel. And, they indicate 'ability to execute' vs. 'vision'. Surely not much more that people developing EA roadmaps need!?..
 
However, for many organisations mandating one tool is not the answer to successful EA. An EA tool portfolio and roadmap can allow different people and material to be brought into the 'fold' and provide a basis for integration. (This is where EA metamodels start to become handy, as well as adoption of standard modelling notations such as BPMN). There are several Enterprise Architectural maturity assessments around. Looking at the tooling needs for the different dimensions being assessed is one way of identifying tool requirements and priorities.  
 
A couple of specific thoughts on the report:
 
It'll be interesting to see how IBM takes forward the Telelogic suite (and the access it now has to EA groups in various companies). And also how it deals with the potential synergies/overlaps/duplication between various modelling products such as System Architect, Rational Rose, Tau Modeller ... as well the requirements management tools (Requisite Pro and DOORS, though the latter has quite a mature following in the government and defence areas).  
 
SAP: Aris (IDS Scheer) and Mega are still tempting for organisations with large SAP investments.
 
Microsoft isn't listed specifically (always interesting to see how Enterprise Architects react when you mention Visio). Visio is not a 'proper/traditional' enterprise architecture tool. However, many organisations do have models in Visio and most of the more sophisticated tools will support Visio import (and in some instances export)  eg System Architect's improved Visio import capability makes it easier to leverage some of that existing collateral. Over the next few years, as Microsoft's "Oslo" takes shape; as the gap between design and implementation reduces, it will be interesting to see how things change. Portals (eg SharePoint and Visio 2007 +) will provide many organisations with a way of quickly providing interaction/discussion around models - outside of the traditional EA group.
 
Perhaps surprisingly (or not), there is no explicit reference to SOA in this EA tool assessment. Many of the tool vendors listed do provide SOA support linked into the broader EA capability to varying degrees.
 
Irrespective of what people think of the content of the Gartner EA tool Magic Quadrant many "decision makers" will look at this when considering tools and that is sufficient reason to at least skim the report.
 
Andrew
 
(As an example of a set of detailed EA tool features see http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v4.2.pdf )

Posted by Andrew Manning at 11:53 AM | Permalink | Comments (2) | TrackBacks (0)