Our Co-Chairman Kris Gopalakrishnan recently mentioned "Sustainability will be for the 21st Century what the Internet was for the 20th" For the Corporates to harness this change, Enterprise Architecture should enable this.
By Brahma Acharya
We all realize that SOA and Cloud computing go hand in hand and are complementary in nature. After all we talk, about everything as a service (XaaS) in the Cloud world. So the immediate question that comes to mind is, would the service that has been designed to be consumed in-house would serve equally well if it were hosted on the cloud? The answer apparently is "Not really". Services designed as per SOA principles (clear contract, standalone functionality) would probably be much easier to migrate to Cloud, but there certainly is a need to re-look at some of the design patterns that will be crucial in cloud orienting the services. Let's identify some of the crucial ones.
by Infosys SOA Architect Community
One of the biggest concerns that our clients highlight to us in any large scale SOA implementation is performance. "Will my application meet the NFRs? Will it scale up as I have more and more service consumers?". These are the most commonly asked question from our clients. And there is a reason for that. Web services technology have become the de-facto standard to create and expose services. Web services, be it SOAP based or REST based rely heavily on XML suite of technologies. XML is notoriously bulky and is slow to process (yes..there are optimization but that is another story) thereby making SOA applications slow performing. And Performance is something nobody wants to compromise on. Then there are concerns of security and complex deployment process which are more pronounced in a SOA based application.
At this risk of sounding like a management, motivational speaker there is one consistent piece of advice that I give to IT organizations over and over and over again when undertaking large initiatives: start small and build in incremental steps. This is particularly true for Enterprise Architecture groups. It is in this spirit that I recommend the adoption of agile methods within the Enterprise Architecture groups, even if agile is not used within the application development groups of the organization.
Agile methods can be successfully applied to all sorts of Enterprise Architecture activities, but to illustrate its applicability let’s look at how agile applies to the development of a standard technology platform for application development. What I mean by a technology platform is a set of standard technology components and reference architectures that can be used by application development projects within the organization, such as a platform for e-commerce applications, or a platform for Java-based, web development, etc.
While we’re on the subject of using agile development, I’ll also cover what considerations one might take into account while defining a technology platform to maximize the benefits of agile methods in application development.
First let me level-set with quick a definition of agile.
In the recent Garner report “Ten Criteria for Choosing an External Service Provider for Your EA Effort", 3 of the 10 criteria related directly to the architects from the External Service Provider (ESP):
6.5 Does the ESP Have a Standard Approach for Identifying and Developing Architects Within Its Pool of Consultants?
6.6 Does the ESP Have a Standard Way of Describing Architects' Levels of Competence?
6.7 Does the ESP Have a Consistent Way of Staffing the Right Architect With the Right Skills on the Right Project?
Gartner is quite right to include these in their criteria. No issue has nagged the Architecture profession in general and the Enterprise Architecture discipline in particular as the challenge of identifying and developing architects.
I’ve often said that we play a cruel joke on most architects at some point in their career. Since most architects start as developers they spend years learning to take large problems and efficiently break them down into smaller and smaller pieces until finally they get to a level of detail that they can readily translate into code. Then after having proved their analysis skills sufficiently they are promoted to architect and told to do everything they used to do except backwards.
The programmer’s skill is analysis, but the core architect’s skill is synthesis. This is not to say that architecture doesn’t require a great deal of analysis, but the critical step in architecture is often re-assembling the pieces into new higher-level constructs in order to get to that which is “architecturally significant”. This is synthesis.
In his book “A Whole New Mind: Why Right Brainers will Rule the Future” Daniel Pink points out that analysis is a left-brain-directed skill, but synthesis is a right-brain-directed skill.
Changes are taking shape. Some are evident, many are like undercurrents, yet not prominently visible but slowly moving the needle, like global warming. I'm talking about the changes in the industry with respect to future of IT and IT organizations. Where businesses stand today and what they need in future, how much ready are IT organizations to make it happen for them?
By Murteza Salemi
Information in SOA world is often considered only within the context of specific services and processes whilst the most awaited gains and benefits of SOA investment is business information availability throughout the organization and to its partners and regulators. When an organization embarks on SOA and integrates its internal systems across LOB’s it will soon discover that there are inconsistencies in its information that was not visible before as it was hidden within various silo applications and data sources.