tag:blogger.com,1999:blog-285680192024-03-23T10:54:00.173-07:00SOA and Enterprise ArchitectureTilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-28568019.post-2135981423224821672009-10-22T21:05:00.000-07:002009-10-22T21:09:15.899-07:00Enterprise Architecture is ImportantAn 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. <br />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!<br /><br />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.<br /><br />They key is business to IT alignment and this is the stepping stone towards its achievement. <br /><br />Would be happy to describe more on how to shape the enterprise architecture for an organization in a methodical approach.Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com3tag:blogger.com,1999:blog-28568019.post-1085678134643921012009-02-11T04:53:00.000-08:002009-02-11T04:54:38.777-08:00Documenting Software ArchitectureSoftware 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.<br /><br />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.<br /><br />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. <br /><br />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.<br /><br />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!Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com6tag:blogger.com,1999:blog-28568019.post-81547386524999680102009-02-03T22:31:00.000-08:002009-02-03T23:57:57.055-08:00SOA Governance - The book is out!<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxEkow8xOf6xHuoxlvdPutOUA9mwuCXffGK21D2a7zq30TYfuEsyI0Kf8e3Sob9Fr4aEhOP8xBzMoq6MXJSYMb8-CLBgHsCNfu9CkuO5eo4AkC8qtc_jjD2stR0kHCgfYQUg0q/s1600-h/book_image.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 132px; height: 207px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxEkow8xOf6xHuoxlvdPutOUA9mwuCXffGK21D2a7zq30TYfuEsyI0Kf8e3Sob9Fr4aEhOP8xBzMoq6MXJSYMb8-CLBgHsCNfu9CkuO5eo4AkC8qtc_jjD2stR0kHCgfYQUg0q/s320/book_image.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5298830636578799410" /></a><br /><br />The most awaited book on SOA Governance is finally out. It has been aptly entitled: <strong>SOA Governance: Achieving and Sustaining Business and IT Agility</strong>.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. <br />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. <br />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. <br /><br />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.<br /><br /><a href="http://www.amazon.com/SOA-Governance-Achieving-Sustaining-Business/dp/0137147465/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1233729435&sr=8-2" target="_blank">Click here to get to the book on Amazon</a>.<blockquote></blockquote><blockquote></blockquote>Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com3tag:blogger.com,1999:blog-28568019.post-92201666720124209022008-08-14T20:15:00.001-07:002008-08-14T20:39:42.860-07:00The SOMA MethodThe 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<br /><br />Who wants to know more ... just drop me a line!Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com7tag:blogger.com,1999:blog-28568019.post-56642445545008907182008-04-25T18:34:00.000-07:002008-04-25T18:46:38.825-07:00Service Modeling and Design - Executing SOA bookI 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!<br /><br />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. <br /><br />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.<br /><br />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!Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com1tag:blogger.com,1999:blog-28568019.post-27677172557110651332007-10-22T18:11:00.000-07:002007-10-22T18:38:53.040-07:00SOA EDA Conundrum - Loosely coupled and decoupled architecturesThere is a common misconception between loosely coupled and decoupled architectures. In fact the misconception is such that people use the two concepts interchangeably.<br />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:<br /><ul><li>Directly invoke the service producer by knowing the service URL a-priori</li><li>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</li><li>Only know directly about the presence of a registry</li></ul><p>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.</p><p>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.</p><p>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. </p><p>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.</p><p>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.</p>Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com0tag:blogger.com,1999:blog-28568019.post-5394013700813209632007-08-01T17:15:00.000-07:002007-08-01T21:33:17.875-07:00Creating an Enterprise Service in SAP is diffferent from creating a Composite ApplicationThere has been some confusion around the mechanism and methodology to create Enterprise Services vis-a-vis the development of Composite Applications in SAP.<br />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).<br />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.<br /><br />Hence, there is an essential difference in methodology in SAP between defining and developing Enterprise Services and developing Composite Applications.<br /><br />I would be really interested to see some more light shed on this topic.Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com4tag:blogger.com,1999:blog-28568019.post-80715954739164874282007-07-16T18:46:00.000-07:002007-07-16T19:19:38.253-07:00Service Granularity Challenge with SAP's ESASAP uses its Netweaver based development infrastructure to define services in a SOA.<br />The business services are defined in Netweaver Developer Studio (NWDS) which is also known as the CAF (Composite Application Framework) Core. They have three main constructs namely an external service, an entity service and an application service.<br />An external service allows for the linkage to services defined outside the CAF Core environment sandbox.<br />An entity service essentially models an operation on a business object (BO) as a service. Typically these map to existing BAPI's that work on business objects that are stored in the SAP Business Warehouse (BW). Operations on business objects being used as a basis to define services, to me, is a very parochial approach to service definition and often becomes too fine grained to follow the footsteps of a service-proliferation-syndrome.<br />Application Services are defined as coarser-grained services that combine or use multiple entity services with some applied business logic to tie them together. Even here, it is more of a bottom up approach to service definition. I fear that, using this approach, we are missing the key issue of aligning services to business processes. The concept of business aligned services seems to be lost in the mechanism, somewhere !!!<br />There is another tool, more of a somewhere-inbetween-a design-and-a-runtime mechanism to define orchestrations of services, based on the SAP Guided Procedures (GP). GP has concepts of actions, blocks and callable objects. Actions and blocks can be simulated as a composition of services together - ala service composition. But then, these service composites, are not pushed down to the business service layer - which to me is an issue.<br /><br />I would love to hear some comments on this.Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com6tag:blogger.com,1999:blog-28568019.post-1148347740499615492006-05-22T16:32:00.000-07:002006-05-22T18:29:00.506-07:00Metadata repository integration conundrumThere is a lot of hype and buzz over metadata repository and management.<br />The main concern or rather an imperative requirement that is becoming commonplace is to come up with a strategy for implementing a centralized metadata repository solution that integrates the enterprise-wide business and technology metadata through a consistent and standard format.<br /><br />For companies that are trying to develop such a metadata integration strategy and implementation, the most common solution is to partner with or buy a metadata repository solution that is capable of realizing the metadata integration dream.<br /><br />But unfortunately enough, various efforts to logically or physically consolidate metadata descriptions into a single, shared and common view is met with the real-world issues of semantic inconsistencies and differences that exist both at the business as well as the technology level. These differences makes it hard if not practically impossible to find a common ground for metadata integration through a repository consolidation.<br /><br />The Business semantic inconsistencies mainly arise from the lack of metadata management policies, procedures and standards that are implemented across the various <em>Lines of Business </em>(LOB's). This is further aggravated by a lack of ownership of the policies and standards by LOB owners and hence the reusability of metadata information is seriously thwarted.<br /><br />The Technology semantic inconsistencies are easier to understand and comprehend. The varied array of technologies e.g. databases, datawarehouses, application servers, business process modeling techniques, business intelligence, etc which are further augmented by the ever-increasing number of vendors offering products and solutions, makes it a real tall order to standardize on an all-technology-encompassing standard for metadata integration.<br />Althogh efforts have been made by Standards bodies e.g. OMG to standardize on an information model for metadata exchange like XMI, it is almost an impossible chase towards attending technology standardization for metadata integration. Consider the commonplace occurrence of competitive vendors trying to provide differentiating solutions through proprietary extensions of the standards and specifications. This alone makes the dream of achieving a semantic consistency between metadata for technologies, impossible to realize.Tilakhttp://www.blogger.com/profile/04588995544794162628noreply@blogger.com5