Tag: solution architecture

Categories
blog

RFP – What goes into it ?

 

 

 

 

 

 

 

 

 

 

 

 

RFP in the age of pay as you use / On demand Software ?

As you could see above the Ruler of Dubai has floated an open tender on his linkedin page calling for a solution to traffic congestion . As part of an IT team we are most often tasked with the task of how to prepare an RFP how to respond it and what does it take to ensuring that you are putting your needs across to that prospective vendor or customer out there to whom it needs to go out to.

In the age of cloud and COTS ( Commercial Off the Shelf ) solutions or software there are customers who pick and choose which software solution to buy based on similar success stories and circumvent the need for a formal RFP. They would most often go with a pay as you use model where with a subscription model you have the software solution at your disposal . But this apart the RFP is not dead yet and there are many formal RFP which get circulated like the one above where the need for pick and choose the right solution from the customer makes sense.

Some of the qualities that you would need while responding to an RFP ?

Understand the customer problem as it stands.

Articulate your value proposition to the customer so that you differentiate from the competition ?

Just because there is a solution it would straight way fit the customer’s context.

How are you going to take of customization needs from a solution fitment point of view.

What is the type of language / taxonomy that you would use when you interact with the business folks . Is it same as the IT side of things ?

Do you understand the jargon and the nitty gritties referred to in the RFP ?

Are you technically competent to see the solution in its entirety or are you from the business side of things where you are looking at the solution from a viability perspective from a purely business angle.

Do you understand responding to an RFP has a direct relevance to the development or downstream chain of solutions being offered. Sales promise the world and the reality is delivered by the downstream people.

Ability to think in terms of abstraction is a key asset here . How would you hide the implementation details and look at  a reference architecture to solve these.

How will a reference architecture help you solve these issues , as these shall help creating repeated success in the company and also help iron out issues while solutioning with the client.  What other skills do you find to be lacking here ?

 

 

 

Categories
blog

What are the qualities of a Solution Architect ?

So you want to transition from what you are doing to a role that helps you see customer solutions. There are many solutions for a given problem which one suits the solution the best given the customer context.Most often the tendency is to straight away jump to a problem and start solving it rather than step back and look at the big picture.

So what does the good solution architects have in common.

They are good at communication, good technical  / business background, have a breadth of experience across a spectrum of an area of the industry pie, have an appetite for plugging risk , they can see the high level picture as well go down to the nuts and bolts when needed, they are visionaries , stand for the proposed solution by backing it with a proper rationale and more importantly life long learners.

Here is leaving you with an article that has these thoughts on how to become a solution architect or be better at it if you are already one.

What make a good solution architect ?

What has been your experience that you find is missing among the architect community and what skills are needed to help them look good in front of their peers , stakeholders and customers ?.

Categories
blog

Where does the Solution Architect fit in an Enterprise?

Most often get to hear where does a Solution Architect fit into the overall hierarchy of an enterprise.People often confuse this with the role of an Enterprise Architect and some of them want to be better at Solution Architecture and move up being an Enterprise Architecture.

In an organization context when you are going from Strategy to Execution then it becomes imperative to understand what are the layers in this process,

Typically it shall be going from
Contextual —-> Conceptual —–> Logical ——> Physical.

As can be seen in the picture attached the Solution Architect is pegged at a layer between the conceptual and logical layers of the strategy to execution process. And the Enterprise Architect is mostly at the contextual layer where business problems are present at a particular context.

If you are wanting to better at Architecture and being Agile at the same time and such resources shall help you keep updated with resources for architects. Do send a mail to maileturnti@eturnti.com with subject Subscribe.

Togaf Trainings and Consulting : http://eturnti.us7.list-manage2.com/track/click?u=171856f3ca74842f465089b2b&id=67c266dd99&e=3d9b3ab567

Solution Architect Training :    http://eturnti.us7.list-manage1.com/track/click?u=171856f3ca74842f465089b2b&id=600fe9d5d3&e=3d9b3ab567

Agile Architecture Trainings : Mixing Agility with Architecture   http://eturnti.us7.list-manage1.com/track/click?u=171856f3ca74842f465089b2b&id=600fe9d5d3&e=3d9b3ab567

Categories
blog

Want to be a better Solution Architect ?

Most people undertake a Course or Certification when they are in between jobs or are looking to test the waters on their market potential. A certification kinda of validates that need as you are better off from the herd when you have that certification. But a certification alone will not help you to get there. Most concerns of people wanting to play the role of an architect would be .

1. I have played various roles but have not been officially given an architect title in the company . How should I move into one ?
2. I have all along been into lead roles / managing projects and delivery but never played the role of an architect in a project.
3. I have worked along side different architects and have seen project / delivery folks donning architecture roles . Can I do the same for my career progression ?
4. You want a role change having been a manager for many years now you want to see the other side .
5. You have got your hands dirty with having worked on many different products and solutions and now want to spend time architecting with the customer in mind as you better understand product and solutions.
6. You have been all along working alongside products and solutions and now can better steps into the shoes of a customer to understand what they need ?
7. You want to apply all that you know regarding a domain but are not customer facing to be able to influence and add value to the final architecture ?
8. Are you in the midst of all the above kinds of queries ?

Want to read more such architect snippets like these please mail on maileturnti@eturnti.com to subscribe.

Categories
blog Videos

Using TOGAF® Framework as Tool for Business Transformation….

Joint introductory webinar with KnowledgeHut on 23 Jan 2015.

Like all presentations mostly end up starting with a glitch , this one also started with one . Please watch it from 3:51 onwards.

Overview:

Business is always in a constant state of flux- more so these days, with disruption happening all around. How do you move from your AS IS state to TO BE architecture in your enterprise transformational journey? What mix and match of people, processes and technology will you blend together, and in what proportion, to drive enterprise value to deliver transformational results? TOGAF® framwork has a suite of tools that can help architects to chalk out the architectural roadmap for enterprise success. This talk will also focus on how agility is an underlying thread in this framework, and how value is delivered incrementally, making the process robust and bankable.

This webinar is an introductory session to walk one through how TOGAF® as an enterprise architecture framework has proven best practices that can be used to drive results.

Key Takeaways:

Exposes the audience to the features of TOGAF® framework which help plug business technology gaps.
– How TOGAF® Standard has agility at its core to drive transformational results.
– Why it is a good skill and knowledge for a seasoned IT professional to have in their kitty.

References / Acknowledgements

1. www.opengroup.com/togaf
2. http://forums.juniper.net/t5/Industry-Solutions-and-Trends/Meatballs-and-Spaghetti-how-to-untangle-the-cloud/ba-p/121808
3. Roger Sessions — http:/msdn.microsoft.com/en-us/library/aa479371.aspx/

Categories
blog

ROI on TOGAF Certification for an IT Professional….

 

TOGAF_ROI

Most often get asked this question by experienced, very experienced and people with little experience folks on what happens to my career if you are certified in TOGAF 9.x ( version immaterial) . For that matter lets look at what is the value add from get that additional degree or title against your name that you get out of any certification or a degree.Most often you still need real world experience with it to make sense of any learning be it certifications or degrees.Some thoughts on what motivates people to look at acquiring these ….

1. Your resume looks impressive.                                                                                                           2. Potential job offers may flow for you in that direction                                                                           3. May get me a pay hike or increase or a lateral or job move.                                                             4. Gain knowledge and become a trusted authority or person and look like a seasoned IT professional who can now talk the same mumbo/jumbo and gain professional respect.                   5.Currently do not have the title of an architect / Want to move along the career as an architect and may be the certification can help                                                                                                   6.Have been entrenched deep down with a specific technology and domain and look forward to see the whole picture.

While the above are some common concerns. Lets look at the value proposition of TOGAF though not covering all aspects in its entirety.

TOGAF Elevator Pitch

TOGAF value explained in an elevator pitch can be stated as it is a methodology to manage your architecture while moving from AS IS to TO BE state. Mind you , your AS IS can be anything from that reflects your current IT landscape. You can be in anywhere on your journey towards accomplishing your mission and how do you go towards getting there all the while caring about agility and not keeping an eye on cost and accountability on your IT spend.

TOGAF helps one understand the nuances of IT transformations(digital is more cool now) and what is involved.

What does getting certified in TOGAF mean ? Industry values experience when it comes to solve complex problems out there at that the customer has. You as an architect has to step in and do the magic of having the right mix of people, process and technology to deliver what is needed to ease the end user pain point. Companies in the least value a person who has such certifications with the idea that such an exposure will help a person at least think in that direction instead of being raw with no experience except for some deep dive experience in say one particular area. It helps you have a T profile for an architect. Helps one scale from a solution architect to an enterprise architect. It helps you to look at the problem from a broader perspective of how it impacts the stakeholders in the company , outside , skills , technology and process to have them all work towards your mission /vision as a company.

A fool with a tool is still a fool – TOGAF No Exception

It is akin to a person clearing PMP need not necessarily be a good manager. As any framework it does expose people to a good set of principles while dealing with people , process and technology and the inherent value in applying them in practice. At the outset it is too general but with applying the organization context to it , it becomes meaningful. Which augurs with the sentiment that a fool with the tool is still a fool. Mere knowing the framework without knowing how it can be tailored for an organization is what makes it abstract for people not having the relevant experience in business and IT transformations. The other reason also being the maturity of the organization who tend to relate the pieces of the framework by the book in a prescriptive fashion without checking on what suits their organization context. Same with agile prescriptions where have heard people say scrum says so we do it. Not really checking on how much of it is really relevant in their particular context. Scrum purists may dismiss this as SCRUM BUT , reality is different and not necessarily by the book. Togaf does not inherently project itself as having a strong agile backdrop to it. But the principles are very much there and it is for the practitioners to present that flavor to the end audience with agility at its core.

Customer Sentiment – What do you know about my problem and context ?

As can be known from experience there can be no single silver bullet to IT transformations , each customer is a case study in itself. The larger the portfolio , the more difficult it is to straight jacket it into a group. Experience comes by walking alongside the customer apart from the knowledge at hand.They call this as Management by Walking Around ( MBWA) instead of an MBA alone.  TOGAF exposes architects to a methodology which mature organizations have used as best practice and earned value. Many of the companies in the fortune list have used it extensively and have tailored them to suit their stack and solve their individual issues. 

 

Categories
blog

Architecture Partitioning and why do you need it ?

Architecture partitioning is a concept used most enterprise architecture frameworks often to separate concerns on how you partition your architecture based on various concerns. You can have the concerns such as length,breadth, time and domain as the parameters for slicing your architecture. Recently wrote a white paper for using enterprise architecture for being used in rural governance for rolling out micro finance solution to the rural population. Let’s say the architecture has lending, savings , schemes , offers and subsidy modules as different parts to the micro finance architecture as shown in the figure below. These parts form a part of your vertical slicing. You can go ahead and partition your architecture based on the vertical slicing which includes generally functional features of your architecture. Horizontal slicing your architecture means slicing your architecture based on technical features or features that are generally non functional . But it can also mean features that cut across horizontally across your architectures features.

architecture_partioning

For the sake of discussion  relating to rural governance in India let’s say Aadhaar ID being on similar lines to SSID in the US. Although there is still a lot of hue and cry on loopholes in the system on account of Aadhaar ID and the debate that it is not functional in the practical sense on many aspects. All said and done let’s put those issues behind us and say it is approved in full measure. As per the Aadhaar mandate there needs to be a case where savings account of people for whom government would roll out subsidies so rolling out such a feature would require the below steps.

These features are central to every functional features and cut across domains. So they would generally be horizontal features.

1. Linking all savings accounts of people in need of subsidies .

2. Releasing the actual subsidy to the accounts of the account holders.

3. Let’s we want bio metric authentication for accessing all functional modules that have integrated with Aadhaar ID and since this concerns across all modules it can also become a part of horizontal partitioning.

Togaf Architecture Partitioning

architecture_partioning_togaf

 Courtesy :  www.opengroup.org/togaf9.1

As seen in the picture above from the open group Togaf 9.1 website, it shows how architecture can be partitioned right from strategy architecture to segment architecture to capability or solution architecture. You can compartmentalize your architecture concerns into one of the following partitions. This would be the length wise partitioning . You can partition your architecture based on architecture domains(business,data,application and technical) of your architecture and that would be the breadth aspect to architecture. You can plan your architecture work based on time based iterations and that would the architecture time based iterations.

Issues with moving directly to Solution Architecture 

Some companies directly get into the solution architecture phase without much investment in the enterprise architecture phase based on their needs. A mature organization is able to move seamlessly from strategy to the solution architecture without issues. The issue is if you move directly to solution architecture then you have a tendency not to abstract common pieces of work that can be useful across other engagements and you can lose out on a reference model for your architecture. It would be more like you may have to specifically tailor a solution every time there is a need for one instead of driving the changes from strategy in which case your drivers , goal and objectives are well defined for your architecture. Ideally a mature organization is one where strategy and grounds up work are in tandem and gel well. In disconnected scenarios they would in silos where strategy is not well understood by the ground force and so such organizations do not invest in strategy due to pressures of quicker delivery. As an organization you will be judged by how well you can move from strategy to solution and vice versa in the long run. There are no doubts that a strategy well executed and understood by one and all in the organization is better than having no strategy at all. This would lead to chaotic processes and finally no accountability on overall architectural pieces and their execution.

These are recommendations from standard frameworks such as Togaf use what suits your context to enable you to better manage your architecture iterations.

Architectural Partitioning on the Server Side used in many deployment scenarios.

serverside_arch_partioning

In a typical web deployment architecture the server side components can be partitioned based on server side functionality offered. This can be factored in the design across all tiers starting from the browser end till the database. Having a modular design of course helps in big monolithic architecture , big ball of mud. So breaking up the modules on the server side helps avoid big ball of mud scenarios and also helps server side dependencies well. Instead of creating one executable or war file on the server side it can be deployed as many different war , ear files if you are coming from the J2EE side of things. Similar logic applies for .NET and other technology stacks. How do you design for modular architecture end to end is in itself needs a detailed treatment. But this is to drive home the point that architecture partitioning as a term can also be looked at for creating modular architectures among other things discussed above.

Categories
blog

XML or JSON which one to use ? What is the tradeoff ?

XMLVsJSON

Most often in projects we need to make crucial decisions when there is a need to freeze upon a standard , language or simple as a standard. Let’s say we have a simple design decision to be taken such as which is a better standard for messaging in the project where we are set with the task of say transmitting an account details from the UI of a bank for account validation. In this case let’s say our decision is influenced by legacy and we have some backend that understands XML then the natural choice would be XML of course if there is free will option left to choose. This is simple and straightforward. Let’s say some folks in the team are voicing in the favor of JSON saying that it is really simple and it understand Java Script and that the handshake between the front end code using java script and the messaging structure can be better coupled , as a architect / manager or IT decision maker how would you approach this problem. Obviously the expectation is that you need to have used at least one of them or at least be able to understand the nitty gritties of both and what they entail.

Which one to choose ( XML or JSON ) ? 

Let’s first get to know what is the likely usage of these standards in our application , this a good starting point as will ensure what is needed most for the scenario. It is not a good idea to have multiple standards being used across your application. 

You want to have a simple messaging style format across your application. 

Both XML and JSON are ideal candidates as long you keep your messaging format simple and not too verbose ( XML pitfall). Both are good simple ( if kept simple XML) , extensible , open and are interoperable as well.

You need to send across binary data or complex data across the wire.

If you need to transmit audio, video , images , chart , graphs kind of information then XML is a better choice for this as there is built in support for this . JSON is more for text and number like data which can be framed within lists and arrays. The flip side is JSON is simple and as it does not have this feature you can say that it is in a way secure for simple means of communication where hacks due to malicious exe and code cannot be embedded in the message format.

You need to send data alone in various related formats and not a whole complex document 

XML is good when you have to send document style data with attributes and meaningful hierarchical data which can be defined extensively using attributes and nodes. JSON on the other hand is useful when you want to send key value , array ( nested ) based data back and forth.

You need to create a markup language or new language with semantics to make some configuration easy.

Let’s say you want to customize some configuration for your customer and make it simpler for him to enter configuration data. You can go ahead and create a language with special semantics , this is easier done in XML with supported parsing and logic added to the code along the side. At times while the definition of this is easier it is tough to write the compiler semantics for the processing engine to act on behalf of the XML. JSON would not be used here where expression needs to be evaluated for example.

You want to reduce overhead with scripting languages such as java script , python etc.

JSON is an ideal choice here as the data format already resembles the notation available in these languages and it is reduces the overhead of conversion from one format to another. XML can also be argued to be a best fit with library support from the languages and scripting platform.

Overall both have their pros and cons and based on your context you can trade off one against the other and use it for your purpose. If it is an n-tier application it would not be a surprise where there is a XML end tier talking to a JSON tier with conversion / adapter logic written in between them , this would ensure both co exist where the need for them is justified in the application. This kind of trade offs are most often done in day to day decision making where architectural decisions are impacted based on what feature necessitates the use of a technology, language, platform or scripting .

It does not make sense to go with the latest on the shelf or our team likes this feature lets use it or that is the new thing on the block. Anyways these can be dealt with when technical leadership meets maturity and is backed with good experience having dealt with such choices.