Showing posts with label Enterpise Architecture. Show all posts
Showing posts with label Enterpise Architecture. Show all posts

Wednesday, July 20, 2011

Single Point of Failure in Enterprise Computing

With SOA as central body of thinking, lots of enterprises are adopting:

  • Centralized Authentication system ( more fancy name is Single Sign On – SS0)
  • Master data management – MDM
  • Queuing services – generally JMS
  • Enterprise Service Bus – ESB
  • Integration utilizing Hub and Spoke system
  • Business Process Management (BPM) Engine

If you look very carefully in all of these systems has one underlying philosophy – Centralized logic and control. These component with fault tolerant and clustered deployment get benefits of distributive computing but still hardware is still co-located.

Does this mindset bring single point of failure in enterprise computing?

My take is: YES. How to minimize this – wait for future posts.

Friday, February 18, 2011

Does Enterprise need SOA for Integration?

One of the most overlooked requirement in Enterprise as well Integration Architecture is seamless replacibility of enterprise applications ( custom made, off the shelf, Cloud, Enterprise Information System, etc). For example, enterprise XYZ wish to replace Siebel CRM by Salesforce. To achieve this target, Enterprise IT has to develop customizations on Salesforce and integration harnesses with other EISes.

Certainly, customization of Salesforce need to be developed but can Integration harness development is reduced to minimum. If Integration has followed the SOA in true sprit then YES but if Integration has followed SOA by using just Tools and platform then NOT.

Decision is yours.

Thursday, February 17, 2011

Complexities in enterprise IT infrastructure (dev, test, UAT, training, prod etc) landscape

  • Non synchronized down time of systems/Applications
  • Simultaneous development & testing (varying projects) on
  • Satellite systems/applications
  • Integration layer/components
  • Varying number of instances of each system/application (satellite as well as integration layer)
  • Simultaneous presence of multiple integration platforms as well as their multiple versions
  • Continual introduction and retirement of system/application in environment
  • Synchronization of data across environments
  • Growing/reducing data flow within network
  • Continual introduction and retirement of B2B partners
  • Support and maintenance of this cobweb

Thursday, July 9, 2009

Book Review: 97 Things Every Software Architect Should Know Edited by Richard Monson-Haefel: Publisher- O'Reilly Media, Inc.: ISBN- 10: 059652269X

This book introduces new concept of book writing – Community Book. And to pleasure of Open Source supporters, book is available under Common Creative License.

Book consists of 97 aptly written essays about Software Architecture barring technical details but focused on Business and human behavior. Book does not mention any vendor and technology specific details which makes universally applicable. Unlike other Software Architecture books which are highly loaded with UML, patterns and other technical details this book covers practical day to day practices for software architecture.

97 Things Every Software Architect Should Know is crisp 200 pages long. Few of the participating authors are well known authority in software while some are hidden gems who yet to be discovered. Few of the authors have their own site and blog which will give insight into their work.

1 Allison Randal (The lead developer for Parrot)
2 Barry Hawkins
3 Bill de hÓra (Co-editor of Atom publishing protocol)
4 Brian Hart
5 Burk Hufnagel
6 Chad LaVigne
7 Clint Shank
8 Craig L Russell
9 Dan Chak
10 Dave Anderson
11 Dave Bartlett
12 Dave Muirhead
13 Dave Quick
14 David Ing
15 Doug Crawford
16 Eben Hewitt (Author of SOA Cookbook)
17 Edward Garson
18 Einar Landre
19 Eric Hawthorne
20 Erik Doernenburg
21 Evan Cofsky
22 George Malamidis
23 Greg Nyberg (author of the WebLogic companion workbook for Enterprise JavaBeans 3rd Edition and is the lead author of the book Mastering WebLogic Server )
24 Gregor Hope (Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)
25 Jeremy Meyer
26 John Davies
27 Kamal Wickramanayake
28 Keith Braithwaite
29 Kevlin Henney (coauthor of two volumes in the Pattern-Oriented Software Architecture series: A Pattern Language for Distributed Computing and On Patterns and Pattern Languages)
30 Mark Ramm
31 Mark Richards
32 Michael Harmer
33 Michael Nygard (Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers))
34 Michael Nygard ( “Release It! Design and Deploy Production-Ready Software” - a 2008 Jolt Productivity Award Winner)
35 Mike Brown
36 Mncedisi Kasper
37 Neal Ford (Author of “The Productive Programmer”)
38 Niclas Nilsson
39 Nitin Borwankar
40 Norman Carnovale
41 Paul W. Homer
42 Peter Gillard-Moss
43 Philip Nelson
44 Randy Stafford
45 Rebecca Parsons (CTO of ThoughtWorks)
46 Richard Monson-Haefel
47 Sam Gardiner
48 Scot Mcphee
49 Stephen Jones
50 Timothy High
51 Udi Dahan
52 Vinayak Hegde
53 Yi Zhou
54 Zubin Wadia (Author of: "The Definitive Guide to Apache MyFaces & Facelets" and "Facelets Essentials: Guide to JavaServer Faces View Definition Framework")

In nutshell book spells out two vital things:

1. Role of a Software Architect
2. What should a Software Architect know apart from technical details?

In starting of book natural question come into mind that why 97, why not 96 or 98 but as you go along with book you do not care about its count. You can get details of why 97 at its site

97 Things Every Software Architect Should Know is already in bookshelf.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading:
1. The Architectural Journal (Microsoft) 15
2. www.bredemeyer.com/pdf_files/role.pdf
3. http://en.wikipedia.org/wiki/Software_architect

One can get more information about book and related topics from:

1. Book’s web presence
2. Amazon
3. Publisher – Oreilly
4. flipkart
5. Barnes & Noble
6. For Indian Customers
7. One More place for Indian Customers
8. Discussion at The Server Side
9. Review by Mark Needham
10. Review by Brian
11. Book Review at Dzone
12. Review at Meme Agora
13. One More Review
14. Another Review
15. The last one

Sunday, July 5, 2009

Standards ???

In IT industry whenever any one architect or design a system/product, few lines about standards are always said. It start with what are the standards are used in development and what standards system/product comply to. You see any data sheet offered by any vendor they boast about standards their offerings comply to. It seems that every body is obsessed with standards.

Does any body giving any thought that what these standards offers in terms of business and technical benefits?
Why there are so many standards (just look at web services)?
Who is offering these standards?
What are the motives of these standards?
Why there are so many vendors are complying with standards?
Are standards pushing us towards a single mold fit all?

Thursday, February 26, 2009

Software Architecture Lifecycle

one my recent Architectural consultancy assignment, questions were raised for architecture life cycle. There is lot of literature about software development life cycle (SDLC) but hardly any on software architecture. In response of these questions I thought of documenting the Architecture Lifecycle.

In the proposed lifecycle I have broken down Software Architecture Lifecycle in five steps:

Step 1: In this step Software architect and stakeholders are identified and their interaction starts.

Step 2
: This step is collection of three sub steps which result in design, documentation and analysis of architecture. These three steps are not very distinct and executed in iterative fashion.

Step 3: In this step realization of architecture take place. Different applications and products are designed and implemented as per the over all architecture.

Step 4: In this step learning from previous steps, historical records, industry trend, business requirements are constantly evaluated and fed back to step 1.

Step 5: This is last step of any architecture. This step is executed in case of obsolesce of current architecture. This step does not executed in one go but in baby steps. It means that parts of Architecture get retired and new things get into it. In rare cases step is executed in totality.

These five steps are not very distinct and get executed in iterative fashion.

Wednesday, December 10, 2008

Enterprise Process Management

Enterprise Process Management should be considered as superset of Business Process Management. In current scenario whenever we talk about BPM we always think of business organization. But in real world every organization is not business organization. There are various organizations which have interests beyond business e.g. government organizations, non-government organizations (NGO), philanthropic organizations, etc. So the term BPM is not sufficient to cater their needs. I propose Enterprise Process Management (EPM) because Enterprise covers not only business organization but also lot of other non-business organizations.

Keeping EPM into sight, what is process?

“A process is a coordinated thread of sequential and parallel activities needed to deliver value to stakeholders.”

So what is EPM?

“Enterprise Process Management is assuming controlling position on processes from inception/idea to its delivery, from very first activity to last, and analysis of each and every activity for continuous and step improvement.”

From definition it is very clear that EPM can be visualized from three view points:

  1. Inventive viewpoint
  2. Execution viewpoint
  3. Improvement viewpoint





1. Inventive viewpoint: This viewpoint is affected by strategic and tactical decisions of any enterprise. Strategic and tactical success of any enterprise demands effective and efficient processes with continuous improvement build in. As environment is dynamic and most of the time beyond the control of enterprise, processes must be adaptive in nature and if possible self-aware.



2. Execution viewpoint: This viewpoint focuses on execution part of processes’ lifecycle. Once process is released in any enterprise for execution purposes this viewpoint takes over. In any successful process this viewpoint has longest duration with numerous small changes but insignificant number of step changes.



3. Improvement viewpoint: In this viewpoint focus is on improvement related aspects of process. This viewpoint gets feed from execution and gives to inventive viewpoint. The improvements may be minor chunks (part of continuous improvement) or quantum leap.



Classification of Enterprises Processes

On the basis of complexity, enterprise processes can be divided into three categories:

1. Material Processes
2. Information Processes
3. Human Interaction Processes


  1. Material Processes: MPs are primarily concerned to “THINGS”. The purpose of these processes is transforming the material and consume resources. These processes rely heavily on Industrial engineering concepts. These processes are found in primarily in manufacturing, assembly, process industrial environment. Generally speaking these processes are so matured over time period across the industries that they more or less resemble procedure or long running procedures. This means the input and output of these processes can be defined objectively.

  1. Information Processes: IPs are primarily concerned to “DATA”. These processes transform data into information or information into more abstract information. These processes rely on Computer science, Software engineering and Information science concepts. These processes are prevalent in service and non-service industrial environment. Again due to tremendous progress in computer science, information science and software engineering these processes resemble to procedures.

  1. Human Interaction Processes: HIPs are primarily focus on human cognitive aspects. HIPs are articulation of subjective issues and getting agreement among various stakeholders. HIPs are based on structure of human communication and coordination, which are prevalent in natural languages and cultures. HIPs are highly affected by cognitive abilities of participating actors and surrounding environment. Most of the time HIPs are highly subjective so their automation is a big challenge.

In real life settings, most of the enterprise processes are combination of MP, IP and HIP.

For simplicity let us consider a simple process: Opening a checking bank account by a new customer.

So to open checking bank account, customer has to submit a form to branch where he wishes to have account. The account opening form also need some supporting document like identity card of the prospect along with letter from an existing account holder. Upon submission of completed form and supporting document, a clerk at branch verifies the documents at preliminary level and sends to regional office for detailed verification. If verification result is OK, account is opened, base branch & customer are informed and checkbook, ATM card are dispatched to customer. If verification result is NOT OK, base branch & customer are informed.

In the first glance the process seems to be well structured and simple enough for automation. This process seems to fall in Material and Information Process category. So automation looks easy and within reach. Now let Human aspect enter into the process.

Mr. Clerk who accepts documents from prospective account holders has friendship with Mr. Tony. One fine day Mr. Tony reaches to branch where Mr. Clerk is stationed and submit Account opening form. Mr. Tony does not was not carrying supporting documents, so he talks to Mr. Clerk and makes promise to submit supporting documents on next Monday and asks Mr. Clerk to hold his docs till then. So human relations start tearing a well-structured process.

Since human interactions and communication is unstructured and asymmetric, so automation of such aspects is very difficult.

Sunday, December 7, 2008

Enterprise SOA Reference Architecture

Here I propose SOA Enterprise Reference Architecture. This is for enterprise and certainly for an application it should be inspiration.



Reference Architecture is independent of platforms offered by various vendors. It is also possible that none of the vendors in market provide complete solution to realize this reference architecture.

Data Persistent Layer

Data Persistent Layer is primarily consists of Enterprise Data - Master, Transaction and Meta. It may also include Datamart and Data driven reporting infrastructure.

In most of the large enterprises Data Persistent Layer consists of relational (RDBMS), hierarchical (LDAP, IMS), unstructured (Emails, chat sessions, file systems, etc) and any other type. These variations in data characteristics warrant unique data handling and treatment technologies.

Service Providers

This Layer consists of different business applications. These applications may be packaged (e.g. SAP, Reteck, etc) or may be custom developed in various technologies (e.g. Java, .Net, etc). Again application in this layer may be service enabled or legacy once, which do not expose their functionalities as service.

At this layer EAI exist. Some may argue that SOA is one form of integration then how EAI can exist at this layer. I will discuss this argument in one of my future posting but not now.
Services Layer

This layer is consists of multiple sub layers which encapsulate different class of services. It encompasses Connectivity Services, Data Services, Business Activity Services and Business Process Services. Each layer in turn consists of other sub-types of services.

This layer exposes different aspects of business - functional and infrastructural aspects. Connectivity and Data services are consisting of Infrastructural services while Business Activity and Process services expose functional Services.

These services though in layers but still breach layered architecture to expose these services independent of layers and for better performance. These services can also be exposed to multiple ESBs if situation warrants.

1. Connectivity services primarily cater to accessing system level functionalities, any adapter & connector services and partner (B2B) integration services.

2. Data services comprises of services, which caters to Business, Technical and Meta data related services.

3. Business Activity Services consist of Atomic business/functionalities and any custom business logic developed by combing one or more Data & Connectivity services.

4. Business Process Services primarily consist of Process integration, Machine and Human centric services. These services primarily comprise of Business Activity services.

Enterprise Service Bus
ESB provides four functionalities:

Orchestration
Routing
Mediation
Enrichment

Some ESBs may provide one more functionality - Choreography. This functionality is associated with BPM systems and currently none of Commercially available ESB provides the same.

Enrichment may be of two types: Data Transformation and Channel Transformation. Most of the analysts & architects keep Data Transformation & Channel Transformation separate functionality.





Presentation Services
These services support various user interfaces (human or machine centric) and let outer world (intra & inter enterprise) interact with enterprises IT assets. The consumers of presentation services are

Human
  • Thin Client

Browser clients: May be based on traditional HTML based or AJAX based

Portable devices: May be based on open standards (WAP) or propitiatory (device or carrier specific)

  • Thick Client

Alway Connected: These clients connect to service providers and consume the services in real time. Traditional think client falls in this category

Offline Clients: These clients do not connect to service providers in Always On fashion but an actor can work in offline mode and when ever connectivity available, services consumed. Java WebStart and Adobe AIR are two most widely used technologies in this field.

Voice Based Client

Voice based clients are gaining popularly to reduce load on contact center. To facilitate this type of user interface, IVR plays great role.

Machine

These types of interfaces are not very obvious but very prevent at enterprise level. Application level interaction (Software to software) and interaction with various devices like RFID tags, Bar code readers, etc (Hardware to Software or vice versa) are part of this type of interfaces.



Integration with Outer World

Most of the large enterprises also get integrated with external world. This integration is both ways - information flow is in both directions. To further complicate the scenario, enterprises increasingly using SAAS. This situation requires special attention and tools. In case of integration with business partners B2B Engine plays major role in conjunction with Partner services. SAAS services may be consumed directly or via B2B engine. In case of Human interaction (CRM - Salesforce.com) B2B Engine should be bypassed but for m/c interaction or substantial data transfer (Document management for insurance companies) B2B engine should be engaged.


Security




Security in SOA is one of the biggest concern due to distributed & heterogeneous systems interacting with each other. The security related aspects should be handled at each level of enterprise. In the proposed model security is considered from physical and virtual perspective. It also takes into account security from network and application view.

At monitoring front it take care of Technical - For support staff, Process & Managerial - For business process owners & managers and Executive - for top rung of business leadership requirements.



Governance

Governance is one of the burning issues in SOA environment. To discuss SOA Governance's Technical architecture, it is necessary to understand SOA Governance model.

Following figure depicts the SOA Governance Model.



The picture below intends to depict SOA Governance Technical Architecture.



Service Life Cycle Management

Service Life Cycle Management essentially helps in managing service life cycle from its conception to decommission. This is one of the vital components, which determine the success of SOA initiative in any enterprise and also its long-term viability.

Rule/Policy Repository & Engine

Rule/Policy Repository contains various Business Rules and Governance & Security Policies. The engine part of the same will help in execution of Rules and Policies as and when demanded.

Service Directory

Service directory essentially consists of UDDI, which facilitates consolidated listing of services.


Event Management

To exploit SOA to its full extent event handling plays crucial role. In SOA environment Events can be classified into three categories


1. Generic Event
Event fired/raised in response of event or interaction with other service/s.

2. Time Based Event
Event fired/raised at particular moment of time to perform certain task

3. Heart Beat Event
Event fired/raised by services at regular interval to announce its existence and may be level of throughput it is working.

Generic Event Handling

These are events which fire/raise other events or results due to interaction of services in ecosystem.



1. Event Generator generates events with minimal data set.

2. These events should be formatted as per the event protocol defined in ecosystem, so that theses event are available to entire ecosystem for further processing.

Ø Event Pre-processing: Check that mandatory attributes are present in the incoming events
Ø Event Refinement: Introduce the other system-generated attributes like start time etc.
Ø Situation Refinement: Check the target status on which action would be performed
Ø Impact assessment: Required result assessment after that impact applies on the target

3. Event factory determine the specific type of action, which the given event have.

4. Event listener executes the specific action, which stated at the specific action code. There we have some general action apply to all type of system is present in generic action code and specific to specific action is present in the specific action listener

5. Event listener executes the action and calls the required system to complete it.

6. Some event, which completed their actions, and no further support needed from any other services are terminated

7. Some events which need further processing from some other services or may be generate other event in response of event is send back to the event engine

8. Event in response of event is again run as a new event and again it initiates its processing cycle in the event engine

Time Based Event Handling

Scheduled event delivered to a service at specific time in the future. Event deliveries can be deferred for short periods of time (such as seconds or minutes) or for long stretches of time (for example, hours later for batch processing). Until that delivery time, the Event is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.



Heart Beat Event Handling

Heartbeats, a common software construct, verify the continual operation of a specific service. With heartbeats, a targeted service continually broadcasts a signal across its environment. System works normally when client services can detect a targeted service's heartbeat signals

There is number of interdependent services in SOA ecosystem such that, if one failed, others will also fail.

Heartbeat generally propagated across SOA ecosystem using publish/subscribe paradigm.



Transaction Management

Transaction Management is one of the most difficult aspects of any enterprise architecture due to varying level of understanding among stakeholders, various technological platforms involvement and spread of transactions – intra & inter enterprise.

In general any enterprise grade transaction framework follows ACID but due to presence of long running business processes and involvement of asynchronous communication traditional ACID becomes irrelevant. To accommodate long running business processes and asynchronous communication relaxed ACID is used which allows violation of ACID but with capability of correcting the violations in reasonable time period and with little business impact.



SOA capable enterprise grade Transaction Framework should have following features:

· Multi level undo/redo
· Coalescing of transactions
· Automatic aggregation of nested transactions
· Supports batching of transactions (Aggregation)
· Rollback of aggregated transactions for error recovery
· Listener support
· Synchronous and Asynchronous Transaction
· Compensatory Service
· Transaction Propagation

Exception & Error Management

Exception & Error Management is consist of
Exception & Error Handling
Exception & Error Logging
Exception & Error Notification
In any enterprise under SOA ecosystem Exception & Error Management poses following challenges:

Exception & Error Handling

No predefined format for passing exception information among participating services
Web services do not have capability of maintaining stack trace
Lack of common exception vocabulary across enterprise

Exception & Error Logging

Scattered logs across services/applications
Varying formats of logs across services/applications
Toggling logs at run time is service/application dependent

Exception & Error Notification

Every enterprise/LOB has its own unique notification requirement
Toggling Notification at run time is necessity
SLA and exceptions are coupled
To counter these challenges there must be a comprehensive Exception and Error Management framework which can manage at enterprise level and form the foundation for Remediation framework.

On the high level, Exception and Error Management framework’s architecture can be depicted as follows:









Remediation Framework

Remediation framework plays very important role in any SOA ecosystem. It can be though of extension of Error & Exception Management and Transaction Management frameworks. Remediation framework leverages Error & Exception Management Framework by utilizing logged error & exceptions. It also supplement Transaction Management Framework via helping to implement relaxed ACID where human intervention might be needed. Remediation framework also makes whole of SOA ecosystem robust via utilizing compensatory services.



Relationship

In SOA ecosystem Security, Governance, Operations, Quality are closely related. Each face of SOA ecosystem affects other.







Documents

Saturday, December 6, 2008

Book Review: SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects

Book Review: SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects by Matjaz, Ramesh, Pooranchandra and Frank (ISBN: 978-1-904811-17-6)

At first glance this would appear to be another "me too" title, and while in some ways that may be true. However there are a couple of things that set this book apart and it can be of value to those experienced in Integration & SOA as well as those new to the subjects.

Those who are new to the book I will recommend read as much as possible and this book must be one those. This book covers basic essentials of Integration, SOA, WebServices and BPEL in very simple and lucid language, which can help any greenhorn.

The most important part of this book is its language. The most glaring lapse in this book is assuming SOA means web services.

It has explained concepts of EAI in very concise & to the point in first chapter. While explaining Integration Infrastructure authors have drawn nice picture, which covers almost all aspects of integration tool stack. But in the section of Integration Technologies section, it fails to mention that MoM, TPM, ORB, App Server and ESB are various generations of the same and no word about “Several hybrid and proprietary products”.

The second chapter covers SOA in technology agnostic as well as Java &. Net specific way. This chapter nicely covers basic concepts of SOA, which include not only ESB but also web services and its Java and .Net implementation. This chapter also tries to cover process-based architecture in the end, which makes things little bit clumsy.

The third chapter covers XML, Schema, XML document security, and XML parsing. This chapter covers a lot but also leaves behind a lot. It totally neglects non Java XML parsers.

The forth chapter seems to be inspired from IBM’s eBusiness patterns. This chapter also touches Web Services Interoperability (WS –I) stuff, which is pretty elaborated.

The fifth chapter covers BPEL and integration with emphasis on process orientation. This chapter is good reference for BPEL and especially Oracle way of BPEL in its Fusion Middleware.

The last chapter covers ESB in detail. The name of the chapter and content of it does not match.

The most wanted but missing part in this book is references for each chapter in particular and for book in general.

In summary I would suggest that this is a good book for anyone involved in SOA and integration project. It will provide a good introduction for those new to the discipline of Integration and SOA. While acting as a useful refresher for those with more experience




go and grab the book at packtpub.com

SOA and Business

SOA is for business enablement. It is for business to help manage IT assets more effectively and efficiently.

IT assets in general may be viewed from three perspectives.

  1. Enterprise
  2. Application
  3. Product

Enterprise perspective include IT assets at inter and intra enterprise level. It considers Business value of IT assets on enterprise level; so it’s effects is also enterprise level. This perspective is generally elaborated in terms of inter and intra enterprise integration. This perspective is generally taken care by CIO and CTO level while deciding enterprise wide IT strategy. Enterprise Architects also play major role in shaping this perspective.

Application perspective limits IT assets within the boundaries of application – off the shelf or custom-made. This perspective considers Application or its significant functionality as service. This perspective makes sense to VP Engineering and CTO. This perspective gains significance in case of purchasing new enterprise application.

Product perspective becomes very important for product developing companies. This perspective focuses on the services offered within a product. Proper usage of this perspective helps in construction of robust and flexible product/product family. This perspective assumes significance for Technical Architects.

All three perspectives help business to save on cost and decreasing the recurring expenses in terms of maintenance & support. They also helps in reducing time to market.

SOA also brings technological breakthroughs which helps in cost saving and fasten the introduction of products in market.

  1. Increased reusability of components/services.
  2. Ease in integration – inter and intra enterprise.
  3. Increased pace of development and adjusting IT assets as business evolve.
  4. Facilitation of incremental construction (architecture, design & development) of IT assets.
  5. Facilitation of geographically dispersed development in varying time zones.
  6. Facilitation in outsourcing/off shoring the IT assets – construction and maintenance & support.
  7. Facelift of legacy application and integration of them in modern IT landscapes.
  8. Increased utilization of human resources.
  9. Reduced and managed risk with respect to legacy IT assets and resources.

Sunday, November 30, 2008

SOA Components




  1. Application Front end: Generally it is web browser based but thick client is also preferred in some cases.

  2. Service: In most of the real time implementations it is Web service but other types of services are based on CORBA, RMI, etc.

  3. Service Repository: If service is implemented using Web Service, it is UDDI (Universal Description, Discovery and Integration)

  4. Service Hosting Environment: In most of the implementations it is ESB ( Enterprise Service Bus)

  5. Contract: If service is Web Service then contract is WSDL (Web Services Description Language)

  6. Implementation: It is web service in most of the cases.

  7. Interface: In most of the cases it is Web based ( SOAP over HTTP)

  8. Business Logic: It can reside in any language, platform.

  9. Data: It can reside in any language, platform.

SOA Principles


  • Follow the standards

  • Optimize the granularity of service

  • Make conscious decision that when not to use SOA

  • SOA is gradual process, do not emulate Big Bang.

  • SOA effectiveness is not in number of services but in reusability and compos-ability of services

  • SOA is for application and also for Enterprise, make conscious choice

SOA Evolution

First Generation: Client Server



Second Generation: With Service Repository


Third Generation: With Service Hosting Environment (SHE)






Challenges in adopting SOA

Business Challenges


  • SOA is a strategic decision not the tactical

  • Vendor centric SOA view

  • Resistance to standardization

  • Fear of losing control


Technical Challenges



  • Lack of technical understanding

  • Re-usability of services

  • Isolated implementation of SOA

  • High demand on network and hardware

What & Why SOA ??

What is SOA
SOA is an architecture style, which exposes business or technical functionalities as reusable, compos-able and self describing stateless service over network.

Advantages of SOA

There are only three advantages of SOA:

  1. Re usability
  2. Frugality of IT Assets
  3. Agility
  • Business
  • Technical


All other advantages can be derived from these three.


Business & Technical Case for SOA

Business

  • Fast pace business environment
  • Customers taste change
  • Merger, acquisition & split
  • Change in business processes & procedures
  • Ever changing legal environment
  • Ever changing IT environment
  • Never ending race for cost cutting


Technical

  • Spaghetti of technologies
  • Independence from Technology and/or Vendor
  • Shrinks SDLC efforts
  • Reusable, compos-able services available over network


SOA offer the following advantages over traditional approaches to distributed computing:

  • Business services across the platforms
  • Provide location independence
  • Services need not be at a particular system or particular network
  • Completely loosely coupled approach
  • Authentication and authorization support at every level
  • The search and connectivity to other services is dynamic

Short-term benefits of implementation:

  • Enhances reliability
  • Reduces hardware acquisition costs
  • Leverages existing development skills
  • Accelerates movement to standards-based server and application consolidation
  • Provides a data bridge between incompatible technologies

Long-term benefits of implementation:

  • Provides the ability to build composite applications
  • Creates a self-healing infrastructure that reduces management costs
  • Provides truly real-time decision-making applications
  • Benefits from the perspective of Business Value Ability to more quickly meet customer demands
  • Lower costs associated with the acquisition and maintenance of technology
  • Management of business functionality closer to the business units
  • Leverages existing investments in technology
  • Reduces reliance on expensive custom development

    When to say NO to SOA

Every one is advocating for SOA. But there must be some scenarios when not to use SOA.

  • In Homogeneous IT environment.
  • When real time performance is critical.
  • When Business and IT environment is static.
  • When tight coupling is advantageous not a disadvantageous.
  • When huge amount of data transfer is happening.
  • When data sharing is in batch mode.

Friday, November 21, 2008

Just Started

In this blog I will try to jouney through software architecture mostly independent of tools and technology.

In this blog I will iterate my thoughts on:

1. Enterprise Architecture
2. Enterprise SOA
3. Enterprise BPM
4. EAI - A2A and B2B
5. Application Architecture
6. Application level SOA
7. Application level BPM