This list is going to get updated as I progress on getting certified as a OCMJEA (Oracle Certified Master Java Enterprise Architect / SCEA (Sun Certified Enterprise Architect):
Links:
http://www.javacamp.org/scea/faq.html#book
http://www.coderanch.com/how-to/java/SceaLinks
http://www.coderanch.com/forums/f-26/java-Architect-SCEA
http://www.whizlabs.com/scea/scea.html
http://www.facebook.com/#!/scea.exam
Experiences:
http://www.selikoff.net/2010/07/16/jeannes-scea-5-part-1-experiences/
http://www.coderanch.com/how-to/java/SceaWallOfFame
http://www.coderanch.com/t/443250/sr/certification/SCEA-passed
Mock Tests:
http://www.javachamp.com/sun-certified-enterprise-architect-scea
http://www.exforsys.com/certification/sun-certification/download-scea-310-051-free-exam-simulator.html
Books:
SCEA for Java EE5 - Mark Cade
Headfirst Design Patterns - Elisabeth Freeman
Java EE5 Tutorial - http://download.oracle.com/javaee/5/tutorial/doc/javaeetutorial5.pdf
Showing posts with label Enterprise Architecture and The IT Architect. Show all posts
Showing posts with label Enterprise Architecture and The IT Architect. Show all posts
Tuesday, 8 February 2011
Monday, 6 October 2008
Webphere Process Server - Features
1: Built on open standards, it deploys and executes processes that orchestrate services (people, information, systems, and trading partners) within your service-oriented architecture (SOA) or non-SOA infrastructure.
2: Extends the value of core applications and databases by centralizing business processes and sharing them across the enterprise, enabling businesses to maximize resources and increase ROI 3: Helps cut costs by enabling flexible business processes with reusable assets, reducing the need to hard-code changes across multiple applications when making changes to existing processes or creating new ones.
4: Ensures compliance with regulations and internal requirements by that business operations run precisely as documented
5: Ensures process integrity to accommodate transaction intensive processes, while providing the scalability, reliability and flexibility needed for future business needs
6: Strong support for human workflow and enables rapid process changes, providing business agility and enabling you to leverage resources efficiently.
7: Operating systems supported: AIX, HP Unix, i family, Linux, Sun Solaris, Windows, z/OS
Thursday, 2 October 2008
FAQ's on IBM's ESB Products
Q. What is an ESB?
A. An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. An ESB can power your Services Oriented Architecture (SOA) deployment by reducing the number, size, and complexity of interfaces between your applications and services.
An ESB performs the following:
1: Matches and routes communications between services
2: Converts between different transport protocols
3: Transforms message formats between requestor and service
4: Identifies and distributes business events from disparate sources
An ESB allows your organization to focus on your core business needs rather that the IT Infrastructure required to connect the programs together. An ESB allows you to add new services faster, and make changes to existing services, with little or no impact to existing services.
As ESBs evolve into control and enforcement points for dynamic management, their new benefits include being able to:
1: Add new services both faster, and dynamically, and
2: Invoke alternative services based on real-time needs.
Q. What are the IBM ESB offerings?
A. IBM delivers the most complete IBM ESB solutions ranging from platform-based, platform-neutral and purpose-built hardware.
WebSphere ESB is a platform-based ESB and optimized with WebSphere Application server for an integrated SOA platform.
WebSphere Message Broker is a platform-independent based ESB and is built for universal connectivity and transformation in heterogeneous IT environments.
WebSphere DataPower Integration Appliance XI50 is an purpose-built hardware ESB and is built for simplified deployment and hardened security.
Q. Why does IBM offer three ESBs?
A. IBM's approach to ESB solutions reflects the realities of evolving IT architectures, which are heterogeneous. One size does NOT fit all when it comes to ESB solutions. Businesses should have the freedom to select ESBs that fit their needs, rather than shoehorn a solution that is not optimal in their environment.
Q. When do I use WebSphere ESB, WebSphere Message Broker or WebSphere DataPower Integration Application XI50?
A. When to Use WebSphere ESB?
1: You use WebSphere Application Server and/or your team has skills with WAS Administration and Java coding or
2: You are now or planning on developing business process using WebSphere Process Server (WebSphere ESB and WPS have common tooling, programming model, and runtime) or
3: You are integrating with ISV business applications hosted on WAS or 3rd party solutions which extend and support WAS or
4: You are mainly focused on standards based interactions using XML, SOAP, Java, JEE, and WS or
5: You want to mediate between Web services and existing systems using JMS, WebSphere MQ, and WebSphere JCA Adapters or
6: Reliability and extensive transactional support are key requirements or
7: You want to minimize your server investment by co-hosting WebSphere services and ESB in one application server.
When to Use WebSphere Message Broker?
1: You are currently using WebSphere Message Broker but would like to extend existing application integration solutions to SOA and related standards or
2: Extend your web services support using WS-Security and WS-Addressing or
3: You have extensive heterogeneous infrastructures, including both standard and non-standards-based applications, protocols, and data formats or
4: You have extensive MQ skills and infrastructure or
5: You are implementing a wide range of advanced messaging and integration patterns including complex event processing or
6: You need extensive pre-built mediation support or
7: You have very complex transformation needs or
8: Reliability and extensive transactional support are key requirements or
9: You have very large files to process or
10: You need the deploy and interact with other ESBs as a remote host or
11: You need to integrate with other applications via the WebSphere Adapters or
12: To achieve very high-performance with horizontal and vertical scaling
When To Use WebSphere DataPower?
1: Ease of use is a primary consideration
2: Simple experience of drop-in installation and admin-based configuration with no or minimal development required or
3: Security, policy and SLA management is required for web services management. Or
4: You are transforming between XML-and-XML or XML-and-any other format
5: Your interaction patterns are relatively simple or
6: You are using XML-based or WS-Security extensively or
7: You require use of advanced Web services standards or
8: You need to minimize message latency when adding an ESB layer or
9: You are doing extensive XML processing combined with high performance requirements
10: Your ESB must be in production very quickly
Q. How do WebSphere ESB, WebSphere Message Broker, and WebSphere DataPower interoperate?
A. IBM's ESB portfolio enables a full range of interoperability scenarios using web services via SOAP/HTTP, JMS, and WebSphere MQ. WebSphere Message Broker and WebSphere DataPower Integration Appliance XI50 now have a single tool and security policy description for optimal security requirements. With a simple click within WebSphere Message Broker, WebSphere DataPower Integration Appliance XI50 will perform WS-Security processing. Applications and message flows will remain unchanged.
Q. What tools do you use with WebSphere Message Broker?
A. WebSphere Message Broker includes the WebSphere Message Broker toolkit which is based on the Rational Software Development Platform which itself is built on Eclipse. The toolkit runs on either Windows or Linux on Intel, and enables the customer to configure the system, develop the message flows and manage deployed environments. The toolkit also provides visibility of adapters (remote or local) in a Broker message flow.
Q. What tools do you use with WebSphere ESB?
A. WebSphere Integration Developer, or WID, is the tool for use with both WebSphere ESB and WebSphere Process Server. WID is designed to be an easy-to-use tool, targeted at the Integration Developer. WID is built on the Rational Software Development Platform which itself is built on Eclipse. WID does not require the user to be a Java developer in order to build and deploy mediations; however it is can be integrated with Rational Application Developer (RAD) for those customers who wish to write their own Java code. Besides WID, other tools available are DataPower tooling, native web UI for administration and configuration of service interactions, WebSphere Transform Extender, XSLT editor, and XSLT maps.
Q. Do I need WebSphere MQ if I have WebSphere Message Broker?
A. Although WebSphere Message Broker is built on top of WebSphere MQ (and is included with Message Broker), WebSphere Message Broker and WebSphere MQ address different business needs. WebSphere MQ provides secure and reliable connectivity between application and systems, supported on more than 80 platform configurations. This provides the ability to move data unchanged between virtually all business environments likely to be deployed in a business infrastructure. WebSphere Message Broker is used as a transport for moving data between applications, but it is capable of performing additional tasks through understanding of data formats, allowing it to provide intelligent routing and transformation of XML data formats. Businesses will still see a need for WebSphere MQ to connect up the multiple different environments that make up the typical IT infrastructure deployed around an enterprise, but are likely to see a need for an ESB to add value in environments where it can act on the structured data being exchanged between standards-based applications.
Q. Are JCA Technology Adapters bundled in WebSphere Message Broker?
A. The WebSphere Technology Adapters are a category, not a product. There are several -- JDBC, eMail, TCP/IP, Flat Files, etc. They are contrasted with the WebSphere Application Adapters such as for SAP, Siebel, PeopleSoft, etc. For WebSphere ESB and WebSphere Process Server, both types of adapters come "bundled" with WebSphere Information Developer. BUT this does not entitle the user to deploy them. The Application Adapters must still be licensed for use. The Technology Adapters, on the other hand, are can be used with WESB/WPS with no license, i.e., the license for their use comes effectively with your license of WESB/WPS. With WebSphere Message Broker 6.1, the Application Adapters are now packaged with the WebSphere Message Broker Toolkit and show up on the palette as Broker nodes. Like WESB/WPS, the customer still requires a license to deploy them. The WebSphere Technology Adapters do not come with WMBT and do not work with WMB, BUT that is OK because WMB comes with a set of nodes (JDBC, File, TCP/IP, eMail, etc) that provide equivalent function and no additional cost is required.
Q. Do I need WebSphere ESB if I already use WebSphere Application Server?
A. Because WebSphere ESB is built on WebSphere Application Server, through their WebSphere ESB license; customers are able to utilize WebSphere Application Server function. In addition, WebSphere ESB also includes additional functions not supplied with WebSphere Application Server (WebSphere Application Server ND edition allows unrestricted use). WebSphere ESB is likely to appeal to many WebSphere Application Server customers who are looking to integrate applications running in their enterprise, who do not want to implement the integration required to link the applications by coding bespoke application logic, either within the application programs themselves or by coding additional adapter logic. WebSphere ESB will allow the integration of applications with minimal programming, with the integration logic being performed on the data 'in-flight' between applications.
Q. If WebSphere Process Server is powered by ESB technologies; do I need to buy WebSphere ESB as well?
A. WebSphere Process Server is powered by the same technology available with WebSphere ESB. This capability is part of the underlying functionality of WebSphere Process Server and no additional license for WebSphere ESB is required for WebSphere Process Server to take advantage of these capabilities. However customers may choose to deploy additional standalone licenses of WebSphere ESB around their enterprise to extend the connectivity reach of the process integration solutions powered by WebSphere Process Server. For example, WebSphere ESB could be installed closer to an SAP application to host a WebSphere Adapter for SAP and to transform SAP messages before sending that information across the network to a business process choreographed by WebSphere Process Server.
Thursday, 27 March 2008
A Table of Contents for a Detailed Design
While this is not a Standard Template and should not be treated as one, it is the result of my attempt to come up with A Table of Contents for a Detailed Design Specification using WebSphere Process Server.
1: Purpose of the Document
The need for a detailed design document is authored here.
2: Scope of the Document
List out specifically what the document covers and excludes.
3: Solution Overview
This section will give a brief background of the implementation of the solution.
4: SCA Elements
All elements of Business Transactions are referred to as Service Components. Examples of SCA elements are as follows:
Access to Web Services
Enterprise Information System Service Assets
Business Rules
Workflows
Databases
This section should list out the SCA Elements.
5: Business Objects / SDO (Service Data Objects)
Business objects define the data flowing between SCA components. Business objects provide an abstraction for data access and are based on a data access technology called Service Data Objects (SDO). SDOs provide a universal means of describing disparate data. Business objects provide rich features to map, manage, and transform data to underlying IT and are described through a standards-based XML schema
This section should list out the SDO’s in detail.
6: CEI
Common Event Infrastructure and the use of a Common Utility Framework for the purpose of:
Logging
Auditing / Archiving / Re Processing
Error / Exception Handling
Notifications
Security
With the Common Event Infrastructure (CEI), service components can emit events that can be captured by business monitors such as WebSphere Business Monitor for real-time monitoring of business processes.
This section should List the specific Events that will be handled by the CUF/CEI.
7: Supporting Services
Supporting services are components that are needed in any integration solution, including data transformation and synchronization services. This Section will list the details of the Supporting Services.
Mediation Flows
WebSphere Enterprise Service Bus provides the ESB functionality, with mediation flows that can operate on messages to perform
• XML-based data transformation
• protocol transformation between various transports
• custom Java operations
• routing
This section will detail out all the mediation flows
Interface Maps
Using interface maps, you can invoke components by translating calls to them. It is possible for interfaces of existing components to match semantically but not syntactically. This is especially true for components that already exist and services that need to be accessed.
This section will detail out the Interface Maps
Business Object Maps
Business object maps, you can translate one type of business object Into another type of business object. You can use these maps in a variety of ways, for example, in an interface map to convert one type of parameter data into another.
This section will detail out the BO Maps
Relationships
You can use relationships to establish relationship instances between object representations of the same logical entity in disparate back-end systems. For example, the same customer’s address might need to be updated in various back-end systems, such as an enterprise resource planning (ERP) system and a customer relationship management (CRM) system. These relationships can be established and managed automatically using the relationships service component. These relationships are typically accessed from a business object map when translating one business object format into another.
This section will list the relationships to be accessed from a BO.
Selectors (Dynamic Service Selections)
You can use selectors for dynamic selection and invocation of different services, which all share the same interface. WebSphere Process Server offers a Web-based interface to enable dynamic updates to the selection criteria and target services, which means that a module that has been deployed at a later time can still be called by this selector component, enabling dynamic changes to the integration solution
This section lists out the Dynamic Service Selections.
8: SCA Element Implementations:
There are Multiple ways of implementing a SC Element
Business Processes
A business process component implements a Business Process Execution Language (BPEL)-compliant process. You can develop and deploy business processes that support long- and short-running business processes and a compensation model within a scalable infrastructure. You can create BPEL models in WebSphere Integration Developer or import from a business model that you have created in WebSphere Business Modeler or any other modeling tool that supports the BPEL standard.
Human Tasks
Human tasks are stand-alone components that you can use to assign work to employees. Additionally, the human task manager supports the ad hoc creation and tracking of tasks. WebSphere Process Server also supports multi-level escalation for human tasks, including e-mail notification and priority aging.
Business State Machines
Business state machines provide another way of modeling a business process. Some processes are easily described as a sequential flow of activities, and they can be modeled as business processes. However some processes are driven by events rather than a sequence, and in this case, the business state machine is a better fit for modeling the process. One example is an ordering process where you can modify or cancel the order at any time during the order process until the order is fulfilled.
Business Rules
Business rules are a means of implementing and enforcing business policy through externalization of business function. As a result, dynamic changes of a business process are enabled for a more responsive business environment.
9: SCA Elements Interface (How to call this component)
By definition, an interface is the place at which independent and often unrelated systems meet and communicate with each other. An interface can be defined by any programming or interface definition language. WebSphere Process Server currently supports a Java interface definition and an XML definition (Web Services Description Language (WSDL) port type). The arguments described in an XML schema are exposed to programmers as SDOs. The WebSphere Integration Developer tooling primarily generates interfaces using the WSDL representation.
10: SCA Elements Reference (What this component calls)
An SCA reference specifies other SCA services that a component uses. These can be soft links that do not have to specify which specific component will be used.
12: Project Build & Design
Libraries
List of Project Libraries referenced / used.
Modules
How the Business Integration Module is developed and the artifacts (services choreography into Business Processes) that are built. Any Import, Export and Service Components that are used should be listed here.
13: Assembly & Deployment
How the Module is packaged, deployed and tested in the development/testing/staging/ production environments.
14: Conclusion
15: Signoff
1: Purpose of the Document
The need for a detailed design document is authored here.
2: Scope of the Document
List out specifically what the document covers and excludes.
3: Solution Overview
This section will give a brief background of the implementation of the solution.
4: SCA Elements
All elements of Business Transactions are referred to as Service Components. Examples of SCA elements are as follows:
Access to Web Services
Enterprise Information System Service Assets
Business Rules
Workflows
Databases
This section should list out the SCA Elements.
5: Business Objects / SDO (Service Data Objects)
Business objects define the data flowing between SCA components. Business objects provide an abstraction for data access and are based on a data access technology called Service Data Objects (SDO). SDOs provide a universal means of describing disparate data. Business objects provide rich features to map, manage, and transform data to underlying IT and are described through a standards-based XML schema
This section should list out the SDO’s in detail.
6: CEI
Common Event Infrastructure and the use of a Common Utility Framework for the purpose of:
Logging
Auditing / Archiving / Re Processing
Error / Exception Handling
Notifications
Security
With the Common Event Infrastructure (CEI), service components can emit events that can be captured by business monitors such as WebSphere Business Monitor for real-time monitoring of business processes.
This section should List the specific Events that will be handled by the CUF/CEI.
7: Supporting Services
Supporting services are components that are needed in any integration solution, including data transformation and synchronization services. This Section will list the details of the Supporting Services.
Mediation Flows
WebSphere Enterprise Service Bus provides the ESB functionality, with mediation flows that can operate on messages to perform
• XML-based data transformation
• protocol transformation between various transports
• custom Java operations
• routing
This section will detail out all the mediation flows
Interface Maps
Using interface maps, you can invoke components by translating calls to them. It is possible for interfaces of existing components to match semantically but not syntactically. This is especially true for components that already exist and services that need to be accessed.
This section will detail out the Interface Maps
Business Object Maps
Business object maps, you can translate one type of business object Into another type of business object. You can use these maps in a variety of ways, for example, in an interface map to convert one type of parameter data into another.
This section will detail out the BO Maps
Relationships
You can use relationships to establish relationship instances between object representations of the same logical entity in disparate back-end systems. For example, the same customer’s address might need to be updated in various back-end systems, such as an enterprise resource planning (ERP) system and a customer relationship management (CRM) system. These relationships can be established and managed automatically using the relationships service component. These relationships are typically accessed from a business object map when translating one business object format into another.
This section will list the relationships to be accessed from a BO.
Selectors (Dynamic Service Selections)
You can use selectors for dynamic selection and invocation of different services, which all share the same interface. WebSphere Process Server offers a Web-based interface to enable dynamic updates to the selection criteria and target services, which means that a module that has been deployed at a later time can still be called by this selector component, enabling dynamic changes to the integration solution
This section lists out the Dynamic Service Selections.
8: SCA Element Implementations:
There are Multiple ways of implementing a SC Element
Business Processes
A business process component implements a Business Process Execution Language (BPEL)-compliant process. You can develop and deploy business processes that support long- and short-running business processes and a compensation model within a scalable infrastructure. You can create BPEL models in WebSphere Integration Developer or import from a business model that you have created in WebSphere Business Modeler or any other modeling tool that supports the BPEL standard.
Human Tasks
Human tasks are stand-alone components that you can use to assign work to employees. Additionally, the human task manager supports the ad hoc creation and tracking of tasks. WebSphere Process Server also supports multi-level escalation for human tasks, including e-mail notification and priority aging.
Business State Machines
Business state machines provide another way of modeling a business process. Some processes are easily described as a sequential flow of activities, and they can be modeled as business processes. However some processes are driven by events rather than a sequence, and in this case, the business state machine is a better fit for modeling the process. One example is an ordering process where you can modify or cancel the order at any time during the order process until the order is fulfilled.
Business Rules
Business rules are a means of implementing and enforcing business policy through externalization of business function. As a result, dynamic changes of a business process are enabled for a more responsive business environment.
9: SCA Elements Interface (How to call this component)
By definition, an interface is the place at which independent and often unrelated systems meet and communicate with each other. An interface can be defined by any programming or interface definition language. WebSphere Process Server currently supports a Java interface definition and an XML definition (Web Services Description Language (WSDL) port type). The arguments described in an XML schema are exposed to programmers as SDOs. The WebSphere Integration Developer tooling primarily generates interfaces using the WSDL representation.
10: SCA Elements Reference (What this component calls)
An SCA reference specifies other SCA services that a component uses. These can be soft links that do not have to specify which specific component will be used.
12: Project Build & Design
Libraries
List of Project Libraries referenced / used.
Modules
How the Business Integration Module is developed and the artifacts (services choreography into Business Processes) that are built. Any Import, Export and Service Components that are used should be listed here.
13: Assembly & Deployment
How the Module is packaged, deployed and tested in the development/testing/staging/ production environments.
14: Conclusion
15: Signoff
Sunday, 23 March 2008
667 - A Failed Attempt
This is for all those who wish to be:
"An IBM Certified SOA Solution Designer"
Well, I appeared for the test only to discover the following:
1: You must attempt a Sample Paper before you take the final exam
2: SW717, SW718, SW719 aren't sufficient to get you to crack it!
3: The "test your knowledge" sections at the end of those modules arent a per cent close to the kind of questions you would be asked in 667
4: 667 is not for people who have their knowledge and experience restricted to Application/Data/Information/Process integration only WITHIN an ENTERPRISE. It is much beyond just B2C integration or plain application integration.
5: It throws scenarios from varied verticals right from banking to manufacturing and healthcare to telecom.
6: If you thought no one uses MainFrames today - you are wrong. There will be hordes of questions on how you would integrate with CICS/VMS/IMS. So an experience with integrating with MainFrames in a B2B as well as B2C scenario is definitely a plus!
7: and like my Brother Anant mentioned in his sms[which truly made me feel nicer abt myself]: "its imp dat u enjoi ur journey in lyf 2 reach ur final destination nd nt get 2 stresd out over d result of 1 damn certification..take it easy nd b chilled..alldmad rush in lyf smetimes makes us forget d achievements we already have made 4ourslvs.."
8: :) smile ! :) therez always a next time :)
Good Luc to all the to be "SOA Solution Designers"!
lots of luc as always
~ sayli :)
"An IBM Certified SOA Solution Designer"
Well, I appeared for the test only to discover the following:
1: You must attempt a Sample Paper before you take the final exam
2: SW717, SW718, SW719 aren't sufficient to get you to crack it!
3: The "test your knowledge" sections at the end of those modules arent a per cent close to the kind of questions you would be asked in 667
4: 667 is not for people who have their knowledge and experience restricted to Application/Data/Information/Process integration only WITHIN an ENTERPRISE. It is much beyond just B2C integration or plain application integration.
5: It throws scenarios from varied verticals right from banking to manufacturing and healthcare to telecom.
6: If you thought no one uses MainFrames today - you are wrong. There will be hordes of questions on how you would integrate with CICS/VMS/IMS. So an experience with integrating with MainFrames in a B2B as well as B2C scenario is definitely a plus!
7: and like my Brother Anant mentioned in his sms[which truly made me feel nicer abt myself]: "its imp dat u enjoi ur journey in lyf 2 reach ur final destination nd nt get 2 stresd out over d result of 1 damn certification..take it easy nd b chilled..alldmad rush in lyf smetimes makes us forget d achievements we already have made 4ourslvs.."
8: :) smile ! :) therez always a next time :)
Good Luc to all the to be "SOA Solution Designers"!
lots of luc as always
~ sayli :)
Tuesday, 11 March 2008
To Succeed as an EAI Architect
As authored by Eric Roch reproduced here with an inclusion (and slight modification) of only the most relevant and notable facts:
The Career Path to being an EAI Architect must include technical and leadership milestones. Often developers overlook the need for strong written and verbal skills needed to produce coherent design documents and communicate the system vision to a team of developers. Once the design deliverables are in place the architect must then act as a technical lead to ensure the design principals are complied with to produce the components that must work together as an integrated system.
For an EAI architect, there is no way around a strong technical knowledge base. You must know the integration tools intimately to define the role the tools will play in a total solution. A solution typically consists of the EAI tools, application servers, web servers and enterprise applications like ERP systems.
The architect must understand where components of the system should be built and how these components interact to create a composite application. The goal of EAI is to integrate disparate system to function as a one. The systems to be integrated, are essentially the components and message flows, broker orchestrations, adapters, etc. are the integration environment that requires design artifacts defining the component relationships.
We effectively treat systems to be integrated as objects with interfaces and message flows into these interfaces. It is therefore critical that the architect has a solid understanding of OOA/OOD and UML.
Another important aspect of creating architecture is the use and creation of design patterns. This is the fundamental means to reuse design artifacts, so a study of design patterns is a requirement for an EAI architect.
We effectively treat systems to be integrated as objects with interfaces and message flows into these interfaces. It is therefore critical that the architect has a solid understanding of OOA/OOD and UML.
Another important aspect of creating architecture is the use and creation of design patterns. This is the fundamental means to reuse design artifacts, so a study of design patterns is a requirement for an EAI architect.
Some design patterns categories that apply to EAI follow:
Enterprise Architecture:
SOA, ESB, Hub and Spoke
Reference Architecture: Composite Applications, Portals, Web Servers
Integration: File Transfer, Messaging, Shared Database
Application Architecture:
Application Server Platform: Model View Controller (MVC) e.g. Struts Model View
Integration Broker: Validate, Enrich, Transform, Route, Operate (VETRO)
Messaging: Publish-Subscribe, Request-Reply, Filter, Routing
Services: Canonicals, Security, Common Error Handler
Business Process Management:
Business: Codified Business Rules
Workflow: Control Flow, Branching and Synchronization, State-Based Instance management and task priority
To Sum it Up:
1. First make sure you have a solid development background in the tool set. You cannot make it to the next level without understanding the tools for EAI.
2. Study OOA/OOD and UML and be able to produce design deliverables with UML.
3. Collect a library of design patterns from books and past projects.
4. Develop your written and verbal skills by looking for opportunities to produce design deliverables and present them to the development team.
5. Look for opportunities to act as a technical lead always seeking to lead bigger efforts to the point where you can lead large projects (from a technical perspective). People skills, negotiation and communication are critical in this step.
I am already acquainting myself with design patterns and a business requirements specification deliverable. Exploring further on both these lines is going to be very interesting.
keep you posted
~ sayli :)
I am already acquainting myself with design patterns and a business requirements specification deliverable. Exploring further on both these lines is going to be very interesting.
keep you posted
~ sayli :)
Friday, 7 March 2008
The 7 Disciplines - of the IT Architect Profession
This is the information I came across on the IBM site publicly available to everyone.
Again one of those pieces of information that i wished to archive here to enlighten myself and others alike.
The IT Architect Profession can be classified in 7 disciplines:
1: Application Architecture
2: Enterprise Architecture
3: Information Architecture
4: Infrastructure Architecture
5: Integration Architecture
6: Operations Architecture
7: Systems Engineering and Architecture
1: Application Architecture
2: Enterprise Architecture
3: Information Architecture
4: Infrastructure Architecture
5: Integration Architecture
6: Operations Architecture
7: Systems Engineering and Architecture
The role of the IT Architect involves listening to clients, understanding their business requirements and defining the structure of information technology solutions. They assist clients on their hardware and software infrastructure and help clients decide which platform is best for their applications. They may also lead the technical sales team in their proposal activity. There are roles that include Technical Sales Architects (which can be on a sales plan – see sales roles), or Test architects. Some of the more common IT Architect roles are listed below:
Infrastructure Architect:
This role concentrates on the design of infrastructures including servers, storage, workstations, middleware, non-application software, networks, and the physical facilities that support the applications and business processes required by the client. Included in the focus areas is the critical evaluation and selection of the software and hardware components of the infrastructure. Infrastructure Architects are responsible for performance, availability and scalability of the infrastructure.
Integration Architect:
The primary focus of an Integration Architect is to design and develop solutions that fully integrate and collaborate with existing IT systems in order to perform an automated business function. These solutions may use different technologies, vendors, platforms, and styles of computing. The Integration Architect has a holistic view of enterprise solutions, including a sound appreciation of operational costs, security, performance engineering, application development and systems management.
Operations Architect:
These professionals focus on the design of systems to manage the infrastructure and applications used by the client. This role focuses on defining plans, strategies and architectures for the installation, operation, migration and management of complex information systems. An Operations Architect gathers and analyzes client I/T needs, translates these needs into requirements for specific systems management processes, products, and services, and may lead or advise the teams which install, operate and maintain the I/T system.
Systems Engineer:
This role provides creates technical solutions for customers in the delivery of complex projects/programs, including complex system integration projects. Their responsibilities span the end-to-end lifecycle of a complex project, from system requirements through delivery and production/deployment, providing technical, architectural, and project management leadership to insure overall solution integrity.
Hope it helped.
Tuesday, 4 March 2008
What's on my SOA Time Table...
The IBM SOA FOUNDATION is an integrated, open standards based set of
The results of SOA Best Practices are:
- Best Practices
- Patterns & SOA Scenarios
- IBM Software for SOA
The results of SOA Best Practices are:
- The SOA Life Cycle
- The SOA Reference Architecture
- The SOA Programming Model
1 Service Creation
2 Service Connectivity
3 SOA Design
4 Process Scenario
5 BPM Scenario
6 Information as a Service
7 Interaction & Collaboration
8 SOA Security
9 SOA Governance
The IBM Software for SOA:
IBM SOA Foundation - Model Phase:
WebSphere Business Modeler
Rational Software Architect
IBM SOA Foundation: - Assemble Phase:
WebSphere Integration Developer
Rational Application Developer
Lotus Domino Designer
WebSphere Portlet Factory
Rational Tester for SOA Quality
IBM SOA Foundation - Deploy Phase:
WebSphere DataPower SOA Appliances
WebSphere Process Server
WebSphere ESB
WebSphere Message Broker
WebSphere Adapters
WebSphere Portal
WebSphere Application Server
WebSphere Extended Deployment
IBM Information Server
WebSphere Business Services Fabric
WebSphere MQ
Lotus Expeditor
FileNet P8
IBM SOA Foundation - Manage Phase:
Tivoli Access Manager
Tivoli Composite Application Manager for SOA
Tivoli Federated Identity Manager
Tivoli Provisioning Manager
WebSphere Business Monitor
Governance and Best Practices
WebSphere Service Registry and Repository
IBM SOA Foundation - Governance
WebSphere Service Registry and Repository
Rational Asset Manager
Tivoli Change and Configuration Management Database
I have started to demonstrate abilities to choose the right mix of Best Practises, Software and Scenarios to implement a SOA for any Enterprise. I need to refine my knowledge a lot more and hopefully the above contents will help me stay focussed and progress in the right direction to elevate my implementation skills.
Good Luc to all those whose share the same Vision as I do! :)
~ sayli :)
Sunday, 2 March 2008
Drivers for using WebSphere Message Broker as an ESB
Typically, WebSphere Message Broker is used to integrate disparate systems. It is designed to transform any format of data between any type of application using any communications protocol or distribution method. It is used where there is a need for high-performance and complex integration patterns.
Consider the following reasons for using a WebSphere Message Broker as an ESB with WebSphere Process Server:
1: You are currently using WebSphere Message Broker and want to leverage existing skills.
Consider the following reasons for using a WebSphere Message Broker as an ESB with WebSphere Process Server:
1: You are currently using WebSphere Message Broker and want to leverage existing skills.
2: You have extensive heterogeneous infrastructures, including both standard and non-standards-based applications, protocols, and data formats. For example, you are using industry formats such as SWIFT, EDI, or HL7.
3: You are implementing a wide range of messaging and integration patterns, for example, complex event processing and correlation, message splitting, and aggregation.
4: You need extensive pre-built mediation support.
5: Reliability and extensive transactional support are key requirements.
6: You want to achieve high-performance with horizontal and vertical scaling.
7: You want integration with other IBM WebSphere and Tivoli® products, as well as third-party JMS providers.
8: You want to natively transform non-XML formats without the use of adapters or user-written data transformations.
9: You want advanced publish and subscribe capabilities, including the use of a wide range of transports; high speed, low-latency messaging; and both topic and content-based routing.
10: You need complex event processing. Complex events are conditions that relate to multiple messages and are defined by applying a combination of logical, arithmetic, and temporal operators to messages or message attributes.
The IntelligentFilter and SituationManager SupportPac™ provides the ability to handle complex events that span multiple messages. Its complex event processing engine enables fast and reliable development of reactive applications, without requiring programming skills.
11: You want to integrate telemetry devices. WebSphere Message Broker can coordinate end-to-end telemetry integration. It can serve as a conduit for passing data from remote telemetry devices into enterprise applications.
Similarly, it can control data flow from command or control applications to remote control devices.
Wednesday, 27 February 2008
WebSphere Message Broker
WebSphere Message Broker is a powerful information broker that allows both business data and information, in the form of messages, to flow between disparate applications and across multiple hardware and software platforms. Rules can be applied to the data that is flowing through the message broker in order to route, store, retrieve, and transform the information.
WebSphere Message Broker offers the following features:
Universal connectivity
– Simplifies application connectivity to provide a flexible and dynamic infrastructure. Routes and transforms messages from anywhere, to anywhere.
– Supports a wide range of protocols, for example, MQ, Java Message Service (JMS) 1.1, HTTP(S), Web services, file, and user-defined protocols
– Supports a broad range of data formats, for example, binary (C/COBOL), XML, industry (SWIFT, EDI, HIPAA, and so on), and user-defined formats
– Supports interactions and operations that allow you to route, filter, transform, enrich, monitor, distribute, decompose, correlate, and more.
Simple programming
– Message flows process and route messages. A message flow contains a series of connected nodes that have the required integration logic that is used to operate on messages as they flow through the broker.
– Message trees describe the data in a format independent manner.
– Transformation options include graphical mapping, Java, extended SQL (ESQL), Extensible Stylesheet Language (XSL), and WebSphere Transformation Extender.
WebSphere Message Broker offers the following features:
Universal connectivity
– Simplifies application connectivity to provide a flexible and dynamic infrastructure. Routes and transforms messages from anywhere, to anywhere.
– Supports a wide range of protocols, for example, MQ, Java Message Service (JMS) 1.1, HTTP(S), Web services, file, and user-defined protocols
– Supports a broad range of data formats, for example, binary (C/COBOL), XML, industry (SWIFT, EDI, HIPAA, and so on), and user-defined formats
– Supports interactions and operations that allow you to route, filter, transform, enrich, monitor, distribute, decompose, correlate, and more.
Simple programming
– Message flows process and route messages. A message flow contains a series of connected nodes that have the required integration logic that is used to operate on messages as they flow through the broker.
– Message trees describe the data in a format independent manner.
– Transformation options include graphical mapping, Java, extended SQL (ESQL), Extensible Stylesheet Language (XSL), and WebSphere Transformation Extender.
Operational management and performance
– Extensive administration and systems management facilities for developed solutions
– A wide range of operating system and hardware platforms supported
– Performance of traditional transaction processing environments
– Extensive administration and systems management facilities for developed solutions
– A wide range of operating system and hardware platforms supported
– Performance of traditional transaction processing environments
Support for adapters
– A collection of software, application program interfaces (APIs), and tools in WebSphere Business Integration Adapters that enable applications to exchange business data through an integration broker. WebSphere Business Integration Adapters rely on JMS messaging.
– A collection of software, application program interfaces (APIs), and tools in WebSphere Business Integration Adapters that enable applications to exchange business data through an integration broker. WebSphere Business Integration Adapters rely on JMS messaging.
WebSphere Message Broker contains a choice of transports that enable secure business to be conducted at any time and any place, providing powerful integration using mobile, telemetry, and Internet technologies. WebSphere Message Broker is built upon WebSphere MQ and therefore supports the same transports. However, it also extends the capabilities of WebSphere MQ by adding support for other protocols, including real-time Internet, intranet, and multicast
endpoints.
endpoints.
Tuesday, 26 February 2008
An Enterprise Service Bus - ESB
This web archive is a result of a preparation that I am undergoing for a variety of reasons:
1: For a Certification
2: Acquainting myself with the IBM product stack for SOA Deployment
3: For my own Interest
4: As a part of the mandatory Skill Set required by my Project
2: Acquainting myself with the IBM product stack for SOA Deployment
3: For my own Interest
4: As a part of the mandatory Skill Set required by my Project
The reproduction here is of course a consolidation of multiple references.
An ESB is an architectural concept that is implemented through the use of one or
more products. IBM currently offers two ESB products.
WebSphere ESB is built on proven messaging and Web services technologies. It provides standards-based Web services connectivity and XML data transformation. WebSphere ESB is shipped with WebSphere Process Server.
WebSphere Message Broker provides universal connectivity, including Web services, and
any-to-any data transformation. In addition, such products as DataPower® and WebSphere Transformation Extender can be used to extend the capabilities of the core ESB products.
An ESB is a key part of a complete solution for connectivity. An ESB might need to be extended or complemented with additional features or products to deliver a complete solution to meet your connectivity requirements.
A Non SOA Solution:
In a non-SOA solution, communication between service requesters and providers is accomplished via a series of direct connections, one connection per requester/provider pair. This requires that the requester be aware of the requirements of the provider and vice versa, for example, the transport protocol, message format, and location of the service. As enterprise solutions grow, the web of direct connections and the complexity of managing those connections
also grows.
A SOA Solution:
In an SOA solution, an ESB acts as an intermediary between requesters and providers. Connections are made to the ESB, rather than directly between the communicating pair. The ESB makes the transition between transport protocols and message formats used by the requester and provider. The location of each service is known to the ESB but not to the service.
The Role of an Enterprise Service Bus:
This decoupling of the consumer’s view of a service from the implementation of a service provides the following advantages:
An ESB is an architectural concept that is implemented through the use of one or
more products. IBM currently offers two ESB products.
WebSphere ESB is built on proven messaging and Web services technologies. It provides standards-based Web services connectivity and XML data transformation. WebSphere ESB is shipped with WebSphere Process Server.
WebSphere Message Broker provides universal connectivity, including Web services, and
any-to-any data transformation. In addition, such products as DataPower® and WebSphere Transformation Extender can be used to extend the capabilities of the core ESB products.
An ESB is a key part of a complete solution for connectivity. An ESB might need to be extended or complemented with additional features or products to deliver a complete solution to meet your connectivity requirements.
A Non SOA Solution:
In a non-SOA solution, communication between service requesters and providers is accomplished via a series of direct connections, one connection per requester/provider pair. This requires that the requester be aware of the requirements of the provider and vice versa, for example, the transport protocol, message format, and location of the service. As enterprise solutions grow, the web of direct connections and the complexity of managing those connections
also grows.
A SOA Solution:
In an SOA solution, an ESB acts as an intermediary between requesters and providers. Connections are made to the ESB, rather than directly between the communicating pair. The ESB makes the transition between transport protocols and message formats used by the requester and provider. The location of each service is known to the ESB but not to the service.
The Role of an Enterprise Service Bus:
This decoupling of the consumer’s view of a service from the implementation of a service provides the following advantages:
1: Reduces the number, size, and complexity of interfaces
2: Reduces the impact of changes made to the format and location of services, both in terms of impact to the applications and in terms of system management
3: Enables integration between disparate resources
4: Allows the substitution of one service provider for another without the service consumer being aware of the change or without the need to alter the architecture to support the substitution
The Basic Capabilities that an ESB should comply with:
The capabilities of an ESB vary depending on the products that are used to
implement it. An ESB should provide the following basic functions:
1: Routing messages between services
The requester sends the request to the ESB. The ESB makes the call to the service provider. The ESB determines the destination for the service provider.
2: Converting transport protocols between the requester and service
Without an ESB infrastructure, service consumers connect directly to service providers using a transport protocol that is supported by the provider. With an ESB, there is no direct connection between the consumer and provider. The service consumer connects to the ESB by using its preferred transport protocol without any knowledge of how the connection to the provider is
made. The ESB sends the request to the provider by using a protocol that is supported by the provider.
3: Transforming message formats between requester and the service provider
Typically, interfaces and operations of disparate services are not identical. The ESB transforms the message from the source into a format that can be accepted by the target. Handling business events from disparate sources. The same service provider that is responsible for a business function can be invoked from a variety of business contexts.
More on Message Broker as an ESB some time later :)
~ sayli :)
2: Reduces the impact of changes made to the format and location of services, both in terms of impact to the applications and in terms of system management
3: Enables integration between disparate resources
4: Allows the substitution of one service provider for another without the service consumer being aware of the change or without the need to alter the architecture to support the substitution
The Basic Capabilities that an ESB should comply with:
The capabilities of an ESB vary depending on the products that are used to
implement it. An ESB should provide the following basic functions:
1: Routing messages between services
The requester sends the request to the ESB. The ESB makes the call to the service provider. The ESB determines the destination for the service provider.
2: Converting transport protocols between the requester and service
Without an ESB infrastructure, service consumers connect directly to service providers using a transport protocol that is supported by the provider. With an ESB, there is no direct connection between the consumer and provider. The service consumer connects to the ESB by using its preferred transport protocol without any knowledge of how the connection to the provider is
made. The ESB sends the request to the provider by using a protocol that is supported by the provider.
3: Transforming message formats between requester and the service provider
Typically, interfaces and operations of disparate services are not identical. The ESB transforms the message from the source into a format that can be accepted by the target. Handling business events from disparate sources. The same service provider that is responsible for a business function can be invoked from a variety of business contexts.
More on Message Broker as an ESB some time later :)
~ sayli :)
Monday, 25 February 2008
I've picked up New Vocabulary! :)
It’s been just less than two months in my Current Role and I have picked up some New Vocabulary. I also made numerous observations in my 1st ever Vendor Evaluation exercise that I had an opportunity to be a part of. Thanks also to the meetings and interactions with colleagues, vendors, clients and numerous other sources which have compelled me to have enough motivation to go ahead and ingrain the new found list of phrases in my blog here! :)
So here you go (the next time you find me using these phrases/words you know where it came from :) ;))
1: Are we there - In terms of getting everyone on the same page?
2: We’ve hit the ground running.
3: I understand where you are coming from.
4: You can’t afford to rock the boat anywhere!
5: Let’s position ourselves correctly.
6: We don’t wish to Poke Holes at anyone :)
7: We can’t boil the ocean in one Talk!
8: Its BAU (meaning Business As Usual).
9: I am just doing a Reality Check!
10: Let’s Sanitize the Process.
11: Does that sound like a plan?
12: Let’s leverage what’s done by our Brothers and Sisters and put a Positive Spirit on it! :)
13: Let us elevate this discussion.
14: Is the game plan still on? (regarding this task / meeting)
15: Can I exercise a timeout – I do not mean to override you.
16: For the lack of better words – …
17: Let’s take a Buy In from the authority.
18: I am unable to articulate that thought.
19: Are we ready to pull the rug on the floor?
20: This is a big kicker okay..
21: We are here to manage the Client’s expectations.
22: They probably got stuck in Limbo Land.
23: Let us talk in Business Parlance.
24: We ought to do more than just an academic exercise here.
25: We will be able to give you a better handle on this.
26: This is yours – Now Run the Show!!
27: With 'abc' the rubber meets the road!
28: Call it whatever you want.
29: I’ll bet my wallet on this.
30: Long Story Short -
31: Every so often!
32: He had an ability to diverge from the proposed agenda and still have everyone on the same page.
33: They are probably looking at instant gratification.
34: It helps to draw parallels between what you have done and what is unique to this engagement.
35: Is there a Strategic Advantage to this?
36: They are making an assurance to take the Client from where they are to where they want to be!
37: We would be looking at North Bound Interfaces which are generic and South Bound which would be more specific.
38: Is this part of the scope / agenda?
39: HA: High Availability & DR: Disaster Recovery
Points 32 to 39 are observations I made and have recorded here as learning’s from the RFP Response presentation that I was a part of. I was the Junior most official in the room of esteemed others like - The Practice Head, the Relationship Manager, a Principal Consultant, a Domain Expert, a Subject Matter Expert, an experienced Resource with both Technical and Functional knowledge from the Vendor Panel and AVP IT, Manager IT, Distinguished Team Members from the Client Side and a Business Transformations Panel, a PM, a set of IT Architects from my company.
My role was to evaluate the solution within the Framework of a SOA based Application Integration approach. Ideally I would’ve loved to dedicate a separate article on it but do not wish to run the risk of violating the Information Security / Business Conduct Guidelines that I always have complied with irrespective of which organization I belonged to. :)
Hope you have a nice time using some of the above phrases and having your own interpretations of them! :)
~ sayli :)
Friday, 15 February 2008
Leadership for the IT Professional
Yes, I did go back on my words, cause Valentine's definitely wasnt the time to Post a piece on Leadership ! :) So here it is reproduced for the curious few, inclusive of me :)
Leadership means getting something done through other people. Leadership is not equivalent to management. Leadership requires the effective coordination of resources that are often not directly under the leader’s control:
• A leader accepts the responsibility for the success of a project or organization and provides selfless giveback and support to ensure everyone’s success.
• A leader recognizes the need to change, adapt, and innovate – and they find effective ways to communicate those needs to the organization.
In order to understand the meaning of architectural leadership it is necessary to understand that any professional can be a leader. Leadership is essential for all IT professionals who wish to progress in their careers.
Examples of leadership in a technical context are:
• Establishing and driving a new architectural vision or direction in order to adapt to changing business dynamics
• Developing a new technical standard or framework as part of a standards body
• Setting and maintaining the direction of a team of IT professionals to achieve a common goal
• Resolving a complex technical problem by developing new tooling or techniques
• Designing a new innovative solution IT architecture that changes the way an organization does business or establishes a new IT industry view or initiative
• Helping the organization to recognize weak links in their technical strategy and implementation in a way that helps to facilitate the organizations closure of gaps
• Facilitating the implementation of a significant and complex architectural initiative through other technical members of the organization – this is often accomplished through mentorship, enablement, and giveback
• Acting in the role of the technical advocate by [recommending] an innovative IT solution that changes the dynamics of the business environment; a technical advocate works with business leaders to consider strategic changes to the business – facilitates entry into new markets – and responds to changing market dynamics.
• Being seen as a role model by team members
Architectural leadership for the Chief/Lead IT Architect is defined as leading the creation and realization of a sufficiently complex system or enterprise architecture that is:
• Critical to the business
• Significant and complex – non-trivial and meaningful to the business
• Innovative
• Recognized as essential across multiple organizations or multiple lines of business
• Visible to stakeholders including, for example, customers or business partners
• Significant and complex – non-trivial and meaningful to the business
• Innovative
• Recognized as essential across multiple organizations or multiple lines of business
• Visible to stakeholders including, for example, customers or business partners
I came across this in my general reading and wished to Archive it in my own blog instead of the usual save / bookmark as favourite. Hope it helped.
lotsa luc,
~ sayli :)
Sunday, 10 February 2008
An IT Architect - Who IS He ??
Okay! So I am an IBM Certified SOA Associate. So ?? What next ??
I have been extremely fortunate to have got an opportunity to apply the techniques for modeling a SOA. Or rather, it was the learnings that I continued to get from my engagements in Vodafone that lead me to get myself certified on SOA.
There is still however, a feeling of unease. It roots from the fact that I am being exposed to a team of IT Architects. A team who has expertise that goes beyond just a product, a framework or a technology alone, and probably I want to see myself replicating those varied capabilities. But, I could get there, only if I made a start. So let me make a start today, by identifying and analyzing if I could elivate my actions, thoughts and knowledge, by archiving and understanding what I found (and reproduce here for your reference,) about the Role, Scope and KRA of an IT Architect.
This surely is a piece of interest to a few, but to those who are interested, chances are that you may also take a step towards being one. So read on ...
An IT Architect defines solutions to client business problems through the reasoned application of information technology. Those solutions are documented as architectures and can include systems, applications, and process components. They may also involve the application and integration of a broad variety of products; technologies, and services; various systems and applications architectures; and diverse hardware and software components.
The role of the Chief/Lead IT Architect is:
• To initiate, business justify, and lead projects for the development of new and sufficiently complex components within the enterprise architecture in the areas of information, applications, and technology, in order to meet business objectives
• To establish an architectural framework that is the foundation for other systems across the organization and is essential for the proper execution and delivery of critical and strategic business systems
• To implement organizational-wide initiatives aimed at supporting the enablement of the IT Architect community through the development of tooling, education, or career enhancement
The Chief/Lead IT Architect is:
• An expert in the understanding of architectural principles and their implications to system design, securability, system extensibility and interoperability, costs, and operational considerations
• A student of the profession that is constantly learning and applying new techniques and technologies and seeks to design new innovative architectural solutions
I have been extremely fortunate to have got an opportunity to apply the techniques for modeling a SOA. Or rather, it was the learnings that I continued to get from my engagements in Vodafone that lead me to get myself certified on SOA.
There is still however, a feeling of unease. It roots from the fact that I am being exposed to a team of IT Architects. A team who has expertise that goes beyond just a product, a framework or a technology alone, and probably I want to see myself replicating those varied capabilities. But, I could get there, only if I made a start. So let me make a start today, by identifying and analyzing if I could elivate my actions, thoughts and knowledge, by archiving and understanding what I found (and reproduce here for your reference,) about the Role, Scope and KRA of an IT Architect.
This surely is a piece of interest to a few, but to those who are interested, chances are that you may also take a step towards being one. So read on ...
An IT Architect defines solutions to client business problems through the reasoned application of information technology. Those solutions are documented as architectures and can include systems, applications, and process components. They may also involve the application and integration of a broad variety of products; technologies, and services; various systems and applications architectures; and diverse hardware and software components.
The role of the Chief/Lead IT Architect is:
• To initiate, business justify, and lead projects for the development of new and sufficiently complex components within the enterprise architecture in the areas of information, applications, and technology, in order to meet business objectives
• To establish an architectural framework that is the foundation for other systems across the organization and is essential for the proper execution and delivery of critical and strategic business systems
• To implement organizational-wide initiatives aimed at supporting the enablement of the IT Architect community through the development of tooling, education, or career enhancement
The Chief/Lead IT Architect is:
• An expert in the understanding of architectural principles and their implications to system design, securability, system extensibility and interoperability, costs, and operational considerations
• A student of the profession that is constantly learning and applying new techniques and technologies and seeks to design new innovative architectural solutions
What distinguishes IT Architects at different levels are leadership, and scope, depth, and breadth of impact. Well "Leadership" is a pretty relative term, but I did find its specific relevance to the IT Architecture Parlance. More in the next post :)
Have a gr8 evening !
~ sayli :)
Have a gr8 evening !
~ sayli :)
Subscribe to:
Posts (Atom)