An enterprise strategy should be to maximize the harmonization between its people, processes and technology. Business processes are the key underpinning of operational excellence; people & technology are important and critical enablers to achieving it. There has to be a robust and scalable framework to make this functional and that framework is the organization's enterprise architecture (EA) strategy.
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.
Thursday, October 22, 2009
Wednesday, February 11, 2009
Documenting Software Architecture
Software architecture has been around as a discipline for four decades. The discipline emphasizes on the structure of software systems and getting the structure right. The discipline came into the limelight in the 1990’s when complex, large-sized IT projects started becoming increasingly popular and commonplace. The popularity saw the emergence of various different schools of thought that doctrinated different views towards software architecture and popularized them through their adherence in real world projects. With the growing number of variations and views towards software architectures, IT practitioners, typically, feel the confusion on which school of thought to believe in.
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!
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
SOA Governance - The book is out!
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
The SOMA Method
The latest version of SOMA - the service oriented modeling and architecture method from IBM has been released. An article on the same -> http://www.research .ibm.com/ journal/sj/473/arsanjani.html
Who wants to know more ... just drop me a line!
Who wants to know more ... just drop me a line!
Friday, April 25, 2008
Service Modeling and Design - Executing SOA book
I am excited to introduce the latest SOA book in the market entitled "Executing SOA - A Practical Guide for the Service Oriented Architect". The book is available for pre-order from Amazon at http://www.amazon.com/Executing-SOA-Practical-Service-Oriented-Architect/dp/0132353741/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1209173802&sr=8-1 and also from other book store sites. It is going to be in the stores by late May this year!
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!
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
SOA EDA Conundrum - Loosely coupled and decoupled architectures
There is a common misconception between loosely coupled and decoupled architectures. In fact the misconception is such that people use the two concepts interchangeably.
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:
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
Creating an Enterprise Service in SAP is diffferent from creating a Composite Application
There has been some confusion around the mechanism and methodology to create Enterprise Services vis-a-vis the development of Composite Applications in SAP.
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.
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.
Subscribe to:
Posts (Atom)
