Category: blog

Categories
blog

Give yourself permission to think differently – Design thinking to the rescue

Here is an interesting news article about how Airbnb solved their problem by redefining their scope.They were stuck as they were looking at how to scale things first before solving other issues. You never know where your potential solution can come from unless you have looked at the problem from all its dimensions.

http://firstround.com/review/How-design-thinking-transformed-Airbnb-from-failing-startup-to-billion-dollar-business/

Thinking outside of the box is a key skill for an architect . It involves being exposed to new ways to think about existing issues. Most often people are so neck deep into finding solutions to problems that they forget to explore other options of how to make things better for people , customers. Most often the architects are disconnected from end user realities and design solutions considering only the technical landscape. This creates a one pointed view of looking at and arriving solutions. Most often the best solutions to customer facing solutions come from the coffee boy , the security guard or the customer who is using the system on a day in day out basis. Have we cared to check what are all the possible solutions which can enhance customer experience before going ahead with the solutions that are merely technology oriented and miss the business outcome or even the end user experience.  Design thinking is a skill for an architect or a solution designer and is a skill that has many people looking forward to which is about getting a problem all out captured in all its dimensions and looking also for problems from all quarters. It does not designate anyone with a Chief of Innovation mantle to innovate on the problem , everyone is a potential out of box thinker. Every input when processed through the design funnel could solve a teething problem with a solution that everyone in WOW !!.

Here is leaving you with a design thinking approach to solve a product rollout issue using principles of design thinking

Categories
blog

Getting your requirements right the first time is all you need…

Most often getting business architecture requirements right is a challenge and it means there are two types of people who need to converge at a common point to where they could make sense it each other. The business people are concerned with the business side of things and look at the picture from an angle which could be quite different from the IT folks. For example the IT team is worried about building requirements that are more better versions of working software or rather refinements in releases but the business is concerned about what business value will this piece add to the overall product strategy or solution point of view. Many a times it so happens that there is no clear articulation of business value and organizations spend time and effort in producing waste or MUDA ( Toyota / Six Sigma ) prefers to call it. This can happen because in the name of taking up an initiative a wrong requirement was envisaged as having to be completed.  Many a times the requirements although is an art and science by itself and needs to be done with the right focus as all the downstream actions based on this can create mis alignment in the vision and mission of an enterprise. So is there is definitive prescription to doing this , how is this similar to user stories or epics that agile teams talk about . User stories are not enough to detail all possible requirements more so when they depict the end to end system goals where aligning business and IT is paramount. This being the case there needs to be a structure to capture all the actors and details that goes into getting a business scenario right.

Recently been to an IT company where the issue was product owners hand over requirements over email or chat sessions or simply over a phone call. It was said that requirements not getting correctly scoped was the single most productivity loss and created enormous amount of wasteful downstream activities. What has been your experience here ?

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

Enterprise Continuum as a part of TOGAF helps innovating at intersections fun…

innovation_eturnti

What is common with Steve Jobs, Mark Zuckerberg both of them have being huge successes in what they offered to the world. They stand for make a dent in the Universe and yes they did it. If you see both of them they did play at intersections and ended up disrupting more than one industry. Steve Jobs combined design and technology and made owing hardware akin to buy vintage art or jewelry. Before him people had given up on hardware which was not good looking and aesthetic, he created awe inspiring products by combining design and technology. Similar is Facebook which combines social and technology to have connected almost all of the world.

Like wise it is when it play at intersections you have multiple opportunities of disrupting more than one field. Likewise when you see many fintech start-ups they are all playing at various intersections.

You have banking intersecting payments.

Payments intersecting retails

Payments intersecting travel

Payments intersecting eCommerce

Loan industry intersecting real estate

CRM industry intersecting credit card industry

Hospitality industry intersects Banking

The list is endless and the possibilities are very many. Playing at intersections has more than one advantage as you are exposed to ideas which flower and cross pollinate when they collide with other ideas and give birth to fresh new design and offerings. This is not possible when you work in isolation in one area. Most often these work best when not compartmentalized in siloed states , they need a continuum or an ecosystem where all people involved in the value chain to the end customer are brought on the same table and it can lead to fusion and myriad colour all coming together.

Enterprise Continuum from the Open Group is one such initiative that aims at connecting the buyer, seller and the internal teams of a value chain together if you were to look at it from Michael Porters famous value chain. This continuum has enabled many an industry to stay connected with their entire ecosystem such as partners , sellers and their own teams delivering on many mandates. One such example of how this would work in practice would be let’s take the example of a Salesforce team which has many partners that it is depended on it and all such information relevant and shareable to both parties will be made available. This means all that can be shared preserving all IP and NDA issues shall be made seamlessly available to both connected parties across the board with the same level of understanding in taxonomy and jargons which bring all parties in an engagement on the same level. The Enterprise Continuum takes this further and extends it to have internal teams , partners and vendors all on this connected platform. Once this clarity is there in the ecosystem it becomes easy to build, integrate, brainstorm, enhance or do anything is required for the moment. This might sound utopian but if implemented well with the support of a visionary leader, it has the power to transform most issues arising out of working in silos across industries.

Dow went from being a Inorganic company to being an Organic Company to being a plastics company to being a food company. These are not simple transformations or transitions. Now they are embracing the culture of innovating at intersections at the intersections of material science , biological science and physics.

Why Enterprise Continuum of TOGAF Amidst Of All This Talk of Innovation ?

 enterprisecontinuum

Enterprise Continuum from the Open Group is quote “The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.”.

In short the above diagram shows how a company can go about organizing its organization artifacts from generic to specific. The more you move towards foundation architectures it would be generic and the more one moves towards the right towards organization specific architectures you narrow down the scope and genericity. The diagram has both architectural and solution assets which allows for abstraction from logical to physical which is fundamental to good architectural work. As you can see a company or organization can starts it journey by beginning with Foundation Architectures and move towards Common Systems Architecture where you have narrowed down your architecture from blue sky generic architecture where the scope of building the most generic architecture is toned down to concentrating on the core domain de-scoping the operating systems and network architecture portions of the same. Now you focus on the industry that you are working on and store industry specific architecture in the industry architecture section. Let’s say you are a developing a banking software then all the other industries that you closely work with such as CRM , Payments , Retail , Financial Services, regulatory services, credit cards will find a place in the industry architecture section. But your focus in the year one of architecture / product development shall be only on building banking software which happens to your core focus area. Again you as a company keeping adding features to your core product, you will refer back to the industry specific architectures to add differentiators in your core product. When you are marrying a core banking product with a payments feature then you potentially refer to the industry specific architectures section of your enterprise continuum and then pick the relevant architectures and go about building your feature. Now this is a value add that Enterprise Continuum brings to the table where you as an organization developing a product also refers to architectures specific to your industry and this can help you in innovating at intersections.

Have such an integrated concept for knowledge and artifacts managements can go a long way in helping a company with innovation at intersections. This means you can work along side product, industry boundaries and if done well you are poised to disrupting more than one industry. Enterprise Continuum also can be created for your specific needs and reflects your journey and what artifacts you as an organization is interested in and help you go back and forth and exploit potential innovation that can happen at boundaries.

Open Group has a extension of this concept where industry specific artifacts for oil and gas, telecom, mining, supply chain are available and companies can become members and look at what is of interest to them by being part of the community and benefit from the same.

They say it is fun “Innovating at Intersections” Enterprise Continuum of TOGAF has an answer to this.  Would love to hear your thoughts on the same.

 

Categories
blog

There are no Pit Stops In Enterprise Transformations really ?

pit-crew-916445_1280

IT Transformation , Digital Transformation , Keeping Your Lights ON while you make changes to your bread winner applications in the Enterprise, move certain others to the cloud, rework on your SMAC strategy, going digital, change your tires while your speeding Enterprise needs to overhaul itself at the same time needs to keep moving and least not loose time at a pit stop.While all of these sound easy to write about but when faced with the challenge of turning your enterprise around , you need a mindset, culture , appropriate tools, talented people who understand the nuances of the change , tools required and how to go about it.

Firstly Mindset : You need to know that people need to change the way they think about the they are standing on a burning bridge with water beneath if you were to borrow a line from the Nokia chief’s mail to its employees. Unless people perceive it this way change is difficult to force it down their throats. Fluidity in all process and people boundaries such that people can reach out and interact with folks across their immediate process lines. This needs a mindset change which can happen when their is strong management support towards moving away from silos and encouraging decentralization.

Be Proactive ALWAYS – Look at the windscreen and not often at the rear view mirror

Usual mindset is look at time, money , resources and progress once you have finished your product or solution. Instead create a pro active process measurement and improvement dashboard where you are measuring everything while moving instead of reflecting when it is all over. This is process independent and no matter which agile methodology you use or which project / process framework you are currently executing. The idea to embed metrics in your journey can be right from the beginning where you look at

1. Review all internal process.

2. Requirements stability

3. Change Management processes

4. Your speed of execution , ability to close projects / activities within time and budget.

5. What market forces are currently influencing your product / solution.

Once you start improving these factors then your outcomes or business results follow on account of these steps or measures.

Tools at the Pitstop

One of the ways to capture these would be to implement a balanced scorecard.

Digital flexibility: 

This key skill would mean how often are you ready to change gears midway and skill / re-skill yourselves when you hit transformation roadblocks.

Integrated Operations data : Ability to respond to complex process data and act on them in real time when transformation is underway.

Experimentation and POC hotbeds : Ability to rapidly experiment test beds where simultaneous low cost fail fast experiments and proof of concepts can be carried out and more importantly reduce the cost of failure.

Data driven decision making : Put check and capture data of all kinds which can be useful to driving change and arrive at decision based on those.

Eliminate , Eliminate all kinds of communication barriers across teams. How do you stop one . Meet review and action on the points that are found as causing delays. Delays can be anything from waiting for snacks in queue in the evening to not getting appropriate sign-offs in time. Teams working on agile communicating with non agile or semi agile waterfall teams can slow things down. Use your own process tailoring to get across these barriers.

Promote quicker decision making using the following concept decentralize implementation and centralize interoperability

Wiping the dust off the screen , spare tires and everything in between.Re work on your strategy when there is a downtime .

What to do when others are racing as hard as you as well.

1. Remember what you are transforming is not only a technology issue and see it is as a business problem and technology is a leverage. Most often companies do not learn

2.  Always eat a part of the pie instead of full fledged transformation on all cylinders. It is nice to say we are changing the whole machinery while the vehicle is moving instead it is better to change the parts one at a time. It is not easy in a large transformation program but things become much easy to test waters when strategy is broken down to segment and then to the solution level. Let’s say 5 competing product lines are ready for transformation and then out of them only 3 are handpicked for transformation , then out of these 3 pick 10 % functionality and iterate and continue this till you can increase your velocity.

3. Get people to meet the change agents often instead of hanging organization change mandates across the hallway, coffee stations , places where your resources spend most time. Else they end up being fodder for light banter during coffee breaks. Strategy should be de-centralized and no one person’s or team’s prerogative to succeed. And communicate , live them day in and day out instead of them being poster board material.

4. Setup innovation and design thinking workshops across the length and breadth of the organization for people to go about doing there jobs with more fun and independence at what they are doing. Do this when during happy days and not so happy days in the company. Make this part of your core routines then it becomes easy to flex think and act nimble.

This is not the full list of course would love to hear from you on what points went to your refueling enterprise journeys.

Image credit : pixabay

Categories
blog

Applying Design Thinking for Product Rollouts.

design_thinking2

All companies have a lot of issues /problem with their product roll-outs or solution delivery mechanisms. Let’s look at how product roll-out issues can be addressed and how design thinking can be used at various stages to help it get to a well-oiled devops machinery where roll-outs are just another day to day affair.

The old school way of approaching to solve would be to define the problem and then try and solve it. Identify what the problem is and then solve it as it is said “A problem identified and defined in most certainly problem solved”.

What does Design thinking tell us? There is no one way of defining a problem and it needs to be looked at its entirety in the complete ecosystem that it manifests or resides and offer holistic solutions around that. It is multi-pronged approach as opposed to find it define it fix it and get over with it. The earlier approach involves straight jacketing the problem into a pre-defined way and then narrows the team into thinking it is limited in its scope and offer solutions around them. This is the reason why solutions although can be cleared off a product management bug tracking list shall not wow the customer or help create awesome products in future.

Learn from anyone and everyone involved in the product roll-out

Whom to involve in this process to get a full rounded perspective of everything that this issue stands for. Since the above one is related to product install and deploy the below mentioned folks can be looked at for brain storming sessions. Involve people from engineering, architecture and also include/take his opinion the courier boy who delivers the tape cut to the deployment folks as well if it applies to your scenario. Involve everyone related and not related as well idea there are no stupid ideas only things that we learn from.

Product managers , domain experts ,developers,architects,QA team, release team, actual users on location, customer end points, production sites at site remote local global and involved in deployment and rolling out patches. Talk to everyone and anyone who could be remotely connected to the issue and whose perspectives can help.

Empathize with team involved in roll-outs, internal and external

Many have pain points , bad UI experience many have database issues, script issues and so on, some of the install tool features need a UI training and are not intuitive enough, some have pre install / post deployment issues, in short it not how the user would have liked to use and see them done.

How can design thinking help here?

To arrive at what can iron out the pain points ask the following questions

  1. What is ? Product roll-outs what is it
  2. What if ? What if we can bundled it all in one piece.
  3. What wows ? One click end to end install – Ideal State
  4. What works ? What is doable in this quarter ?

Define what issues are there in your product roll-out

Let’s say you have all these problems / issues laundry list with you. Now your next level of brainstorming would be to create options or alternatives on how you can make the world a better place for the customer by ticking the bucket list of issues with alternative solutions. There could be more than one alternative for an issue.

Ideate around the various approaches

For an easy and effortless deployment / install of the product pain point, the solutions / alternatives could be as follows

  1. One click install which will explode the entire product in the relevant tree / directory structure.
  1. Create a single war / tar of your product directory.
  1. Pre-populate all your static data in configuration files and provisions to load them into the database during install.
  1. Auto run all the initial SQL seed data by means of a trigger or stored procedure.

Now we see all of the above can be the options for solving one pain point which came out when we created our laundry list. Ideally this can happen as a result of having a design thinking workshop or huddle where one and all concerned are invited and stick their pain points around post it notes.

Now the most important points while tailoring solutions under the context and culture of the end user/customer/roll-out team that you are trying to solve the problem for and more importantly EMPHATHIZE with them. What works best is think you are the one who will actually be using the system. Drive this mind-set in the team. When a group of people think on these lines you shall be amazed at the perspectives that come out. Before you lose all these different suggestions click the post it notes on the whiteboard with a camera and save it for consumption as and when you need refocus on the issues.

All of this produces qualitative data which can then be used to arrive at stories.

Capturing Product Roll-out Stories

Document scenarios where roll-outs have failed and under what conditions and complete the story board with who the actors involved were.

For example the roll-out happened when most of the support staff was on party etc.

Roll-out was not complete as the sys ops person did not have enough admin rights to restore the tape etc.

Weed Out / Flush your Idea board

Weed out ideas from your idea board that lack a wow factor and concentrate only on the top 5 or 6 concerns to start with.

Rapid Prototyping

Row towards the shore like you’re going to run out of fuel anytime and eventually focus your efforts towards building a working model.

Create solutions / stories on which of these solutions shall you apply in create hot beds to prototype solutions around them. Create quick and rapid prototypes of the solutions where it is easy to turnaround if things do not go around fine. Look for the ones which results in a compelling experience.

Test out your prototypes in the Real world

Run the prototypes through multiple test beds and more so in the real production scenarios and quickly run through the results by eliciting feedback with the larger team. Refine Refine Refine and put the feedback /results into the product effectively and action them till you have a product that resonates with the customer well.

Have a product that people fall in love with instead of creating just another product for people.

Categories
blog

Why do DBAs sit in a office corner and other IT’s best kept secrets….?

censorship-610101_960_720

 

“If you want to keep a secret, you must also hide it from yourself. – George Orwell, 1984″ 

With no offence meant to DBA’s or other IT folks mentioned in this piece would like to put across a few of IT’s best kept secrets on the table. It is nice to have them as secrets but why bring it out. It might help someone somewhere to think about it and use this secret for their own good once they know it is a well guarded secret and getting around the secret is actually going to help decision makers circumvent these issues and find solutions to them.

Here is revealing some of the secrets as always somethings were always meant to be a secret and hence they shall not be part of the list here 🙂

1. All technology decisions are made when people concur amongst themselves instead of a great product or solution influencing the outcome.

2. Implementation problems are not your problems once you ship software.

3. The more open the architecture the more complex it can get.

4. If software testing is so difficult, demanding and challenging, then why is it
that we keep on assigning the least skilled or experienced to perform it?

5. Why do DBAs always sit in a corner or in a nomans land and not accessible to most meetings where their key inputs are needed. Applicable not just to DBAs but to all IT folks who have a say in matters and are not accessible during key organization huddles.

6. The security at the gate checks for what you steal out in pen drives and not the grey matter in your head. IP protection needs more full proofing.

7. Hardware perfectly working software does not work. Typical of people stuck chasing delivery deadlines.

8. SMAC rhymes with SMACK ( negative tone to it ) and hence third platform is better.

9. The dirtier the surrounding better the software , great products were created in garages remember. The formal looking office with great furniture can only produce dot releases and not an earth shattering product.

10. Freemium is a way to get more customers to play with your product but they shall not influence the market sustainability in terms of revenue.

11. IBM pays an undisclosed amount of money to Oracle to use the Java TM on IBM JVMs.

12. POCs always beat many a technical arguments. Always a working piece of software trumps arguments about this way or that way. At Facebook this has been the way forward when stuck in a dead end on this v/s that.

13. Public cloud for where you store your private data ( individual level ) and private cloud where you store public data ( company level / storing data of a large group of people) . This has been the norm cloud security can change this.

14. People do not care about privacy enough instead of saying the opposite. That is the reason why all of us have all our private data on public cloud. Emails , pictures , rants , likes , dislikes and six degrees of separation.

15. Many companies take the same client out for dinner and drinks twice. This happens when they do not streamline and minimize conflicting product lines.

16. Google knows a lot more about people and companies than what glassdoor or others forums or your friends can reveal.

17. Sysadmins and QA teams have more camaraderie than other folks in IT among themselves.

18.  If something is offered free to you as a customer then you are no longer the customer but the product itself.

19. Fixed price project on Agile was not feasible until recently. Things could have changed.

21. CMMI has dispensations and you can bypass any of your stringent processes as long your end customer is fine with it.

22. Guys who work on UI are more outgoing and extroverted than the ones working on Kernel / compiler design.

23. A startup CEO life is short lived once it gets acquired and becomes a VP in the acquired entity and is on his way out to another true calling.

24. If you want to stop a product or project from funding delays ask its ROI from the beginning . This is a sure stop way to projects from being executed.

25.  Business IT disconnect is still the hardest thing to do as there are no good men out there you decently understand both.

26. All corporate extravaganzas are inherently unhealthy .Throw pizzas out if you want to celebrate instead order fresh fruits and herbal tea. May not go well with people who are used to junk food.

27. Do not talk of innovation or design thinking unless the revenue has taken a downturn in companies .

This is not an complete list of secrets but is nevertheless has some points to think about to bring in solutions to the above list that can turn enterprises and organizations into fine well oiled machinery. #turnITaround…

“It is wise not to seek a secret, and honest not to reveal one. – William Penn, Some Fruits of Solitude”