Thursday, October 22, 2009
Having a visionary EA is by far the most important first step that any organization should have. An EA is a visionary who understands & predicts how the future of the company may be in 10 years. With that vision in mind she defines a framework for EA through business architecture, application architectures, information architectures & technology architectures. EA should never start from the identification of a technology platform and application suites - a myopic view of the enterprise and a recipe for failure!
A popular misconception is that business processes alone forms the business architecture for an enterprise. Processes form the dynamic view of the enterprise whereas the static view is also imperative depicting a modularized set of 'business' components each fulfilling a set of business functions. These business components needs to be categorized into business competency areas to eventually form a business map that depicts the entire enterpise. Assessments performed on this business map assists the stakeholder to define a prioritization of business initiatives that required IT enablement.
They key is business to IT alignment and this is the stepping stone towards its achievement.
Would be happy to describe more on how to shape the enterprise architecture for an organization in a methodical approach.
Wednesday, February 11, 2009
However, the toughest challenge to software architects comes in the form of finding the Holy Grail on how to document a system or application’s software architecture. Documenting software architecture is as much a science as it is an art form. While the science lies in the proper analysis, understanding and the usage of the proper description language to define the software architecture of the system, the art form assumes significance when a clear, crisp, non-redundant depiction is required.
Software architectures require a very crisp and clear documentation to communicate the developing solution to the business and IT stakeholders. Many IT projects have bitten the dust owing to lack of clarity in the documented architecture artefacts. This lack of clarity introduces a gap between the system’s architecture and the downstream design and implementation artefacts – deviation is inevitable.
Software architects find it immensely challenging to determine how to document software architecture in a way that clearly articulates the solution. While over engineering and excessive documentation adds significant delays and associated risks to project delivery, sub optimal documentation results in a serious lack of the developer’s understanding of the solution architecture – which is expected to define the constraints within which the technology should to be leveraged to develop the code.
What if I come up with a book on this topic? Would you read it? What would you like to see covered in the book? Your wishes may be granted - just speak them out for me!
Tuesday, February 03, 2009
The most awaited book on SOA Governance is finally out. It has been aptly entitled: SOA Governance: Achieving and Sustaining Business and IT Agility.I happen to be an author of the same! We have compiled all our collective field experience, knowledge, wisdom and futuristic thinking on this elusive and hotly debated topic on SOA Governance.
The theme of the book is like this: We go into a company and find out that their SOA and the governance around all SOA intiatives is not working - it is broke and they are begging the question on how to fix it in order to reap the true benefits of SOA.
Through a near-real-world case study we take each aspects of this emerging discipline and provide prescriptive guidance on how to institutionalize SOA Governance in an enterprise.
The idea is that, for any SOA initiative, to follow the practical, well illustrated and prescriptive guidelines that is laid out in this book and implement this at your own enterprise or any consulting engagements where you are helping your client/customer out to address SOA Governance as a discipline.
Click here to get to the book on Amazon.
Thursday, August 14, 2008
Who wants to know more ... just drop me a line!
Friday, April 25, 2008
Being a co-author of this fascinating book gives me a sense of pride and a feeling of satisfaction of having addressed certain burning topics in SOA. There is a ton of work out there that talks about various theories around SOA but the problem arises when the rubber hits the road; when the SOA architect is called upon to execute on an actual real-world SOA engagement. This book is meant to address the practical needs of an architect to execute successfully on an SOA engagement.
One of the chapter addresses SOA modeling and design in a very precise and prescriptive technique that provides ample guidance to the SOA architect to develop an architecture and execute on the same. It introduces the RUP-SOMA method from IBM which has now tasted implementation success in hundreds of real-world projects all over the world. The technique has its roots in three major phases - sevice identification, service specification and service realization. Each phase is dealt in minute details to the point that one can even develop a project plan on executing a SOA engagement from an architecture, design and implementation standpoint.
Let me know if you would like to get a sneak peek on this methodology and I would be happy to blog it with you!
Monday, October 22, 2007
A loosely coupled architecture is one that is evident in the foundation principles of SOA. Based on the degree of coupling a service consumer may:
- Directly invoke the service producer by knowing the service URL a-priori
- Only know about a presence of virtualized service which in turn has the intelligence to route the consumer request to the most pertinent service that may fulfil the request
- Only know directly about the presence of a registry
In SOA the service consumer and the service producer is loosely coupled but there remains an element of coupling between them the degree of which is based on the chosen architecture.
A decoupled architecture is one in which the emitter of a business event has absolutely no knowledge of the potential receiver(s) of the event and what a receiver may do with the event. This is the principle behind EDA. EDA hence is tailor made for asynchronous communication but that is not to say that a synchronous communication is not possible using EDA.
In fact just like you can use SOA for asynchronous communications between the service consumer and the provider you can also use EDA for synchronous and well-defined, predictable communications between the event source and the recipients.
SOA and EDA can certainly coexist and that too in a very compliementary manner. Using both in a hybrid architecture can realize the real-world business requirements wherein both synchronous and asynchronous communications may possibly be required to realize complex requirements.
It is our responsibility as architects and thought leaders to come up with prescriptive architectures and guidance around how to develop a hybrid architecture based on SOA and EDA principles.
Wednesday, August 01, 2007
The identification, development and certification of enterprise services follow a strict internal governance mechanism inside SAP. Enterprise Services are proposed either by the business application suite groups (e.g. SCM, SRM, CRM) inside SAP or by a member of the SAP IVN (Industry Value Network). Enterprise Service definition is a top-down approach, one in which a service is defined in relevance to a business functionality that it tries to solve. It has the much needed business alignment that business-level services ought to provide. Enterprise Services are defined in SAP XI. The message structure are defined first. The message interface is defined by using the definitions of the message structures. A message interface is exposed as a service which is then developed using NWDS and XI and then provisioned into the Enterprise Service Repository (ESR).
Composite applications on the other hand are developed more or less based on a bottom up approach. A composite is created using the CAF-Core and CAF-GP tools of the Netweaver platform. The UI elements are developed either in WebDynPro or Visual Composer. The CAF-Core uses services that are either defined in the ESR or it can create services based on the various back-end systems e.g. CRM, ERP which expose their IT functionality through BAPI's. CAF-Core defines two types of services: Entity Services (encapsulate the business objects from the back-end system) and Application Services (which combine entity services, add business logic on top of them and are exposed to be consumed by the elements of CAF-GP, WebDynPro and Visual Composer). CAF-GP is a mechanism to simulate the creation of business processes through the use of constructs like Actions, Blocks, Processes and Callable Objects. The Callable Objects are used to invoke the Application Services in CAF-Core. Processes at the CAF-GP are subsequently deployed and invoked through the SAP Netweaver Portal.
Hence, there is an essential difference in methodology in SAP between defining and developing Enterprise Services and developing Composite Applications.
I would be really interested to see some more light shed on this topic.