Thoughts Register

Mobility has an important place in the Enterprise Architecture roadmap of all enterprises. Every enterprise is seriously looking at the mobility space and defining strategy and business plans based on mobility. Demand is rapidly growing from both workers and consumers to access corporate and business applications from their mobile devices. In this article, I will highlight trends and analyst predictions in the mobility space, study various options available for enterprises and define a method to strategically build mobility initiatives based on experience gained from rolling out mobile applications. Imperative for Mobility What analysts have to say on mobility: Gartner By 2013, mobile phones will overtake PCs as the most common web access device worldwide. By 2014, more than 3 bn of the world's adult population will be able to transact electronically via mobile and Internet technology. By 2015, context will be as influential to mobile consumer services and relationships

When Architects are involved in the definition of architecture, it is also their responsibility to represent it in such a way that all the audience understands it very well. This is more important when architects are involved in selling the proposed architecture of a solution as part of pre-sales process. They have to present concrete justification points to the potential customers to make them understand why their proposed solution architecture is best. When the solution presentation happens, it may involve various high level stakeholders from business, IT, technology etc. Same is the case when IT of an enterprise is pitching for an imitative or a new project; unless business is convinced, IT will not get a “go” signal and budget allocation. The target audience of architecture can be categorized into two: 1. High level stakeholders like CIO, CEO, CFO, EA etc from business & IT who influence decisions significantly 2. Medium / Low level stakeholders like Tech. leads, develop

As Microsoft’s WCF progresses through new versions, it is gradually becoming a replacement for many existing products and architecture styles. In an earlier post, I had briefed how it can be looked as a best replacement for hub & spoke architecture style. In this post, let us see how it can replace ESB.  If you look at the key capabilities of a typical ESB product, it includes Intelligent Routing, Service Aggregation & Load balancing. If you spend some time of WCF Routing capability, you can understand how it supports “content based routing”. It allows routing of the incoming messages / requests based on the content in the message or in the header. This capability can be leveraged to address the typical techno-business requirements like endpoint virtualization, load balancing, service versioning, priority routing, service aggregation & protocol bridging. Endpoint virtualization: A single router service can be exposed to end clients and it can be configured to route the m

Hub & Spoke architecture style – When it comes to integration in heterogeneous environment, hub & spoke architecture style is the best and proven option. This architecture style can be realized through queues, messages & some routines. The different apps of an enterprise can communicate with each other through message exchanges. Sometimes, the same architecture style is also used for just content based message routing. Some people call it as ‘message based integration’. Messages will have different values in headers indicating their type & other details. Based on the content in the header, each message will be routed through different paths. Message processing will be taken care by routines or batch processes. With the availability of the options like WCF Router in .Net 4.0, it has now become a must to find when exactly to use hub & spoke. Using it in simple places like content based routing will make things complex. While options like WCF Routing is available, hu

Here is a snapshot of TOGAF - ADM Phases ·          Preliminary Phase o    Defining the Enterprise o    Identifying key drivers and elements in the organizational context o    Defining the requirements for architecture work o    Defining the architecture principles that will inform any architecture work o    Defining the framework to be used o    Defining the relationships between management frameworks o    Evaluating the enterprise architecture’s maturity ·          Phase A – Architecture Vision o    It starts with a ‘Request for Architecture Work’ from sponsoring organization to architecture organization o    Key activities : Architecture Vision & Business Scenarios o    Development of Business Scenarios o    Define scope and Validate business principles, goals & drivers and establish EA KPIs o    Stakeholder Analysis should be used to identify key players. o    Identification of Business Transformation Risks ·          Phase B – Business Architecture o    To develop bu

Some of the highlights of the Gartner’s 2010 “End User Predictions” report: By 2014, more than three billion of the world’s adult population will be able to transact electronically via mobile and Internet technology. By 2015, context will be as influential to mobile consumer services and relationships as search engines are to the Web. By 2013, mobile phones will overtake PCs as the most common Web access device worldwide. These highlights indicate how important it is for every Enterprise to have a strategy in place for enabling their enterprise / consumer facing applications on the mobile devices. Even though there is a debate going on whether Native Mobile apps or mobile web apps are best, Enterprises cannot ignore the path in which existing applications should be web enabled, as it ensures a wider reach. Any initiative on mobile enabling web applications will revolve around 2 key concepts: Markups Style sheets Both of these ensure an optimize

When an Architect drafts the Architecture Specification or System Architecture Definition document of a system to be built, it is one of the key requirement to include necessary views of the architecture so that those views will convey how various concerns of different stakeholders of the system are addressed. Usually the documentation includes various views of the architecture like conceptual architecture, logical architecture, technical architecture etc. targeting different stakeholders. Tools like MS Visio, MS Word were typically in use for drafting various views of an application architecture. With the release of .Net 4.0 and Visual Studio 2010, logical architecture diagram can be drawn in Visual Studio itself!   Beauty is not just a simple capability to draw some boxes. But to link the logical architecture (which is called “layer diagram” in MS VSTS 2010 Context) to the actual implementation so that if the system is developed not in accordance to the application’s architecture,

Since the publication of my article “Evaluating Application Architecture, Quantitatively” in the 23 rd issue of Microsoft’s The Architecture Journal , Iam receiving lots of questions / encouraging comments / wishes / suggestions. I never expected such a response back from the architects’ community around the world and result is this follow-up. In the article ‘Evaluating Application Architecture, Quantitatively’ which is outlining the framework for evaluating application architectures quantitatively, it is been specified that for a positive response to every question / statement in the questionnaire / checklist '1' will be assigned and '0' will be assigned for a negative response. When a set of questions / checklist is used for an application architecture evaluation, some of them may not be suitable for a particular context. Say for example, you are evaluating an application’s architecture that is meant for intranet only. So, in that context, assume that you are

Evaluation of an application architecture is an important step in any architecture-definition process. Its level of significance varies from organization to organization, based on a variety of factors (such as application size and business criticality). In some IT organizations, it is a part of a formal process; in others, it is performed only upon special requests that stakeholders might raise. Enterprises sometimes have a dedicated “Architectural Review Board” (or ARB) that is made up of a team of experienced architects who are earmarked for performing periodic architectural evaluations. Scenarios that drive the architecture-evaluation process include: ·          When a business must validate an application architecture to see whether it can support new business models. ·          An expansion to new geographies and regions—resulting in the need to check whether an existing application architecture can scale to new levels. ·          Impaired application performance and

Listed below are the key factors that are to be considered while starting estimation for an application, as they may have significant impact on cost as well as overall schedule. Level of impact will vary based on the nature of the team that is going to carry out the development. Even though we can think that some of these factors are any way considered for estimation implicitly, they are listed here explicitly to ensure that they are not missed. So when we get a RFP to respond, keeping a ‘special eye’ on these factors will help us in arriving at a reasonable ‘ball-park’ figure. Even we can allocate a percentage against each of this factor to indicate the level of impact each one has on overall estimation. After the execution of the project, these percentages can be verified with the actual figures and it can be used as benchmarks in subsequent estimation for similar types of application developments. There could be multiple factors that are related to these percentages. Once these fac

In these days of business where we are living in the world of various maturity models to measure the maturity levels of SOA, software capability etc. I am seeing maturity level from a different perspective.   As the need to build highly available & scalable systems is growing high day by day, unless there is a reasonable level of maturity that exists both on the customer side and vendor side, it is tough to meet the goals. Here, by the word ‘Maturity’, what I mean is awareness and knowledge on the factors like best architectural / design practices, non-functional requirements, QoS requirements, industry standards and their direct impact on the business, based on a business domain, industry and operational nature of the system Some customers are matured enough to clearly specify their ‘Scalability’ & ‘High Availability’ requirements more precisely than others. Some of them will specify it just for the name sake and if a vendor asks do you want high availability, customer then

Cloud computing market is crowded with more and more vendors as it is seen becoming no.1 in the ‘what’s next’ list among the CEOs & CIOs. Google, Amazon, Microsoft are pioneers in this arena. Based on my observations, I can see more tractions on Windows Azure based enterprise apps. There may be many reasons. One key reason that would have made Windows Azure as one of the key choice may be ‘data storage’ facilities it offers. If you see the key players in cloud computing viz Amazon, Google, Microsoft, they are offering data stores based on EAV model: • Amazon – SimpleDB • Google – BigTable • Microsoft – SQL Data Services EAV models are suited only for the scenarios where vast no. of attributes is used to describe an ‘Entity’. From the business domain perspective, ‘Health Care’ can be a good candidate for such scenarios. Especially when data models are designed for the databases to store info on clinical findings, we will end up in lots of attributes. If we design database