- Tell us a little about your organization: Based in Zurich, we offer consulting and training services since almost 20 years. We see ourselves as an independent enabler for the digital transformation, helping our customers getting fit for the digital age. To this end, we use the ‘Glenfis Principle’ – a holistic approach that, alongside theoretical knowledge, attaches particular importance to the mediation of practical skills (competence), which can be used to successfully and lastingly deploy this knowledge in the company or organisation (Implementation).
- What other topics do you teach or consult on? Topics include:
– Cloud & Sourcing
– Lean, Agile & DevOps
– Value Chain Service Models
– Training and Awareness (Cloud, ISO, ITIL, Cobit, Security, Agile, DevOps)
– Security & Cyber Resilience
– Change Enablement - What type of interest in DevOps are you seeing in your region? As everywhere the interest of DevOps is rapidly growing, in Switzerland this in not different. For many it’s really to understand in a first step what DevOps is about and why it is relevant for them. In Switzerland we deal a lot with financial institutes with a high level of legacy and regulations, the question is often how to apply DevOps practices in such an environment.
- How do you think that DevOps contributes to the business’ value stream? DevOps is all about getting faster and better and this is how it positively influences the value stream. And DevOps does it in a holistic way by looking at the value stream end-to-end, from idealization to $$$.
- What topic area in DevOps excites you the most? Dev’s and Ops’ finally talking to each other!
- Why should enterprises and individuals consider formal DevOps Training? Before starting any change initiative, it is paramount that everybody gets a common understanding. This is especially true for DevOps, as it includes a wide range of Agile, Lean and ITSM practices. A training or special awareness sessions definitely facilitates this.
Tag: devops culture
-
REP SPOTLIGHT: Glenfis AG
-
REP SPOTLIGHT: Xellentro Consulting Services
DevOps Institute: Tell us a little about your organization.
Xellentro: Xellentro Consulting Services LLP is an emerging global provider of project, program and portfolio management, IT service management consulting and training services. Established in 2012, with headquarters in Bangalore, India, Xellentro works closely with its clients in tackling their most difficult organizational development challenges. Xellentro is a specialist organization that works with its clients to identify improvement areas and uses experienced consultants to enhance their business and development processes.
While the realm of management consulting is vast and a number of firms provide a range of advisory services—starting from niche areas to general management domains—what differentiates us is our practitioner’s approach where we don’t limit ourselves only to advisory and rather prefer to stay on till envisaged benefits are realized and final outcomes are delivered. We bring in huge experience across industry verticals.
DOI: What other topics do you teach or consult on?
Xellentro: ITIL Foundation, Intermediate, Practitioner, Expert, Scrum Master and Product Owner, PRINCE2, PRINCE2 Agile, MSP, MoP, PMP, Lean Six Sigma
DOI: What type of interest in DevOps are you seeing in your region?
Xellentro: There is interest mainly from corporates.
DOI: How do you think that DevOps contributes to the business’s value stream?
Xellentro: This will be a good extension to the ITSM and with Agile being used everywhere, DevOps will have a great value.
DOI: What topic area in DevOps excites you the most?
Xellentro: The concept of having both Development and Operations working together is very important to finally deliver value to business.
DOI: Why should enterprises and individuals consider formal DevOps training?
Xellentro: To really understand the culture change and not focus on only the tools/automation part of it.
-
Managing Your DevOps Releases Efficiently
The Top 5 Things You Need to Know When Selecting a DevOps Release Management Solution
DevOps is a modern software delivery movement that encompasses agile principles and encourages automation in application delivery. Why adopt it? It allows teams to reduce errors due to manual steps and break down silos between teams to improve communication and collaboration between all stakeholders within the business.
Whether you’re knee deep in a DevOps transformation or just getting started, implementing a DevOps release management solution is an important step along the journey. Why? Because in today’s on-demand economy, organizations must capitalize on any opportunity to improve application delivery throughout the organization, irrespective of the development processes in place.
Based on a recent discussion between Michael Azoff, principal analyst at Ovum, and Anders Wallgren, CTO of Electric Cloud, I was able to glean why DevOps release management is a must for enterprises to modernize the software delivery process and compete at a higher level. More specifically, Michael and Anders discussed the top five requirements for selecting a release management solution, which I’ve laid out for you below.
No. 1: Application Manifest: Model and version applications, infrastructure and middleware.
This is what you’re looking for in an enterprise grade solution—a solution with ease of use in defining an application deployment blueprint, and being able to reuse it and version it and have variations to meet the complex and ever-changing needs of your organization. If you are doing continuous delivery and DevOps correctly, you should never have to make a change to a deployed application by hand—ideally, changes are made to the application model and then re-released into a production environment. This allows you to make and test changes in one place, and easily keep track of everything in production. Having an application manifest is a key facet for a great release management solution.
No. 2: Pipeline Design: Model, version and refactor pipelines, workflows and processes.
This is not only an important consideration for selecting a release management solution, but also is at the very heart of continuous delivery—the ability to define and manage delivery pipelines for complex legacy applications or newer microservices. For large organizations with lots of technical and process debt, being able to flexibly model and manage that sort of complexity is essential.
Ultimately, the whole concept behind DevOps comes down to the idea that there is the “what,” the “how” and the “where.” The “what” is the application manifest, mentioned above. The “how” is the pipeline design. What are all the stages this particular application or component or service goes through? Understanding your end-to-end pipeline is very important. You need to have the end to end of what your software goes through—not just conceptually, but even physically written down somewhere. If you don’t have that that process completely nailed down, you don’t really have a full understanding of what it takes to ship your software. Without this complete understanding, it can be much more difficult to have success. By modeling these pipelines, you allow teams to visualize the flow of value through the life cycle, and make iterative improvements on it in a collaborative and safe manner.
No. 3: Pipeline Execution: Predictably and efficiently deliver legacy and CD-style pipelines and releases at scale.
One of the most important things when practicing DevOps is enabling fast feedback, so getting visibility into pipeline execution as they’re occurring is very important. This provides teams an easy way to troubleshoot problems quickly, and then refactor and optimize the pipeline over time. Enterprise pipelines can be very complex and touch a lot of tools—your Dev team might be using Jenkins and Chef and Selenium, and your Ops team might be using ServiceNow and Azure cloud and Puppet. We have customers that have more than 60 tools as part of their ultimate DevOps toolchain. For each one of these tools or services you need to make sure you’re getting the best performance possible, and operating them as efficiently as you possibly can. As you execute them, the ability to see those executions live as they happen, then collect information about them and optimize your pipeline helps to make the entire process more efficient.
No. 4: Governance, Security: Role-based access control, traceability and auditability.
This is one of the key functions to consider for an enterprise-grade solution. If you just tie together your release capability with tools that still require some manual steps, you’re not able to scale that. This is where a large-scale organization, especially one that is regulated and has auditors, will want a solution that can demonstrate clearly that the whole process is governed such that no one can make a change to the process, environments or binaries without it being logged, and that any change that is made has gone through a QA and testing process. Those are the sorts of things that are really crucial for the Ops people, as they are handed responsibility for ensuring a low-risk environment.
When DevOps was starting, the overwhelming belief around security and governance was, “Gee, this is going to really bother the auditors.” However, it turns out it is quite the opposite—to get good at DevOps and continuous delivery, you really need to automate everything. What do auditors want? They want companies to do two things:
1) Document their process and
2) Demonstrate they are using that documented process.
In the process of sitting down and automating your software delivery pipeline, you are essentially documenting that process. Executing that pipeline gives you the record of what you did: How did we deploy? When? Who did it? What was the pipeline that was used? What was the testing? All of those things are now available to be audited.
No. 5: Integrations: Works with the tools you already use
You want a solution that fits in with the tools and process that you have. It would be a non-starter to show up and say, “Throw away all of your current tools and let’s use this new thing.” It would also be inefficient to have to change your process to fit into some tool’s preconceived notion of how your enterprise should run. Make sure you don’t have to change the way you do business, and that can help the DevOps adoption curve quite a bit.
By keeping these top five considerations in mind when selecting a release management solution, you can help ensure your journey into DevOps and continuous delivery is a much smoother, more efficient and more fruitful one. Regardless of the tools your organization decides to use, consider first how you can make your pathway to production a competitive advantage and reap the benefits of an efficient delivery pipeline!
If you have the chance, take a listen to the full conversation between Michael and Anders.
About the Author/Sam Fell
Sam Fell is the head of Marketing at Electric Cloud, responsible for driving awareness and demand for the company’s DevOps release automation and acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling and implementing DevOps release automation, IT change management and application performance management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft.Sam holds a Bachelor of Arts degree from Illinois Wesleyan University.
-
REP SPOTLIGHT: Soft2Solve
DevOps Institute: Tell us a little about your organization,
Soft2Solve: We work with our customers in order to help them to enhance IT performance, saving cost, and training on best methods, process and practices, selecting at the same time the best solutions for Spanish Speaker Customers.
DevOps Institute: What other topics do you teach or consult on?
Soft2Solve: Cost savings in some specific areas as printing, energy.
DevOps Institute: What type of interest in DevOps are you seeing in your region?
Soft2Solve: The interest is initial. Most of customer are aware of DevOps initiatives, but they are still learning and looking how movement evolves and how they can set up the practices on their companies. Some of them already started with agile methodologies in development.
In the other side, most of them already have ITSM practices implemented, based mainly in ITIL.
DevOps Institute: How do you think that DevOps contributes to the business’ value stream?
Soft2Solve: First, aligning IT with the business requirements in terms of speed, flexibility and agility. Then it contributes to analyze the bad processes in place and getting high cost savings when implementing DevOps practices. It also enhances the internal relationships between IT departments, as usually there is a big fight between them. Also, that impact on quality and speed to answer the business.
DevOps Institute: What topic area in DevOps excites you the most?
Soft2Solve: It is an IT answer to the business requirements to follow the business needs; meanwhile, being more productive and less expensive. In other areas, the automatization is a base for DevOps.
DevOps Institute: Why should enterprises and individuals consider formal DevOps Training?
Soft2Solve: Although sometimes the organizations do not know, any new change—especially culture changes—need internal sponsors as much as possible in the organizations. These people have to be trained by third-party independent people outside their organizations that are aseptic and not influenced from the internal existing culture and way of doing. These people will be the people that will support the change and the IT alignment with the business organization and will answer quickly to business requirements.
-
Iterative Indicators: Measuring DevOps ROI
It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.
The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.
At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.
For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.
With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.
That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.
For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.
Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.
The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.
As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.
Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.
Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.
If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.
Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.
-
REP SPOTLIGHT: getITright
DevOps Institute: Tell us a little about your organization.
getITright: With offices in Australia, South Africa, The Netherlands, Nigeria and Malta and a network of partners operating in 31 countries, we offer a bouquet of services to help organizations to:
- Manage better
- Lower risk
- Perform better
- Make better business and IT decisions
Our service offering includes:
- Training courses – Learning best-practice through our Partner Academy courses or network of training providers
- Accredited IT Best practice course material – License our training material
- Consulting – We use an agile approach for projects and a lean approach for operations when consulting and coaching.
DevOps Institute: What other topics do you teach or consult on?
getITright:
- Service Management: ITIL®, ISO/IEC20000, Lean IT, Service Desk Institute
- Governance of Enterprise IT: COBIT® 5
- Project Management: PRINCE2®, PRINCE2® Agile, DSDM AgilePM®, Scrum
- Information & Cyber Security Management: ISO/IEC27001, NIST Cybersecurity using COBIT5
- Quality Management & Business Improvement: ISO9001, LEAN SIX-SIGMA
- Risk & Continuity Management: ISO31000, ISO/IEC27005, ISO22301
- Cloud Computing
DevOps Institute: What type of interest in DevOps are you seeing in your region?
getITright: DevOps awareness in the region is still low, but we see a steady increase in the level of interest in the topic.
DevOps Institute: How do you think that DevOps contributes to the business’ value stream?
getITright: It makes projects and business as usual faster, more stable, with less risk.
DevOps Institute: What topic area in DevOps excites you the most?
getITright: DevOps enables organizations to improve productivity and respond to change with less risk. It’s easy to adopt by organizations with mature ITSM practices in place.
DevOps Institute: Why should enterprises and individuals consider formal DevOps training?
getITright: Training ensures that all resources in the organization are in sync when implementing new practices like DevOps in an organization and ensures a cohesive approach that facilitates proper organizational buy-in and adoption.
-
REP SPOTLIGHT: Omnikron
DevOps Institute: Tell us a little about your organization.
Omnikron: With over 30 years of industry experience, we have honed IT and project management training techniques to ensure that course material caters to our clients’ needs. Our training is not just lectures from a book. We offer world-class courses, assessments and simulations in a variety of formats and at various paces. As the workplace has changed in the 21st century, so has the training approach here at Omnikron.
DevOps Institute: What other topics do you teach or consult on?
Omnikron: Omnikron’s most popular training includes ITIL, PMP, TOGAF9, Change Management, DevOps, Security & Security Awareness and Cloud.
DevOps Institute: What type of interest in DevOps are you seeing in your region?
Omnikron: There is a lot of talk about DevOps and our classes are slowly but surely increasing in size. Hopefully by the end of the year, we will have a packed house for our classes.
DevOps Institute: How do you think that DevOps contributes to the business’ value stream?
Omnikron: We have honed in on ITIL for years and DevOps is such an easy transition for most of our students. Not only are the students enjoying the class, but they are able to use their past experience to share stories in class as well as apply what they have learned outside the class.
DevOps Institute: What topic area in DevOps excites you the most?
Omnikron: Organization consideration and practices seems to be the favorite among our students. Plenty of dialogue has been given around this particular topic.
DevOps Institute: Why should enterprises and individuals consider formal DevOps training?
Omnikron: Because DevOps is designed to help our student continually improve their services to their internal and external customers. Can’t get any better than that!
-
Q&A: Full City Tech’s Higbee on Culture, Part 2
In part one of this two-part Q&A we dug into Wes Higbee’s position on instilling a DevOps culture. Higbee, a developer and business consultant, continues his separation of wheat from chaff in the field of DevOps dreams.
devopsy.kinsta.cloud: How is automation, which is a focal point for DevOps, also a trap?
Higbee: Focusing on the automation can become problematic if you forget about other things. Something like automation will distract you and you’ll end up having great turnaround times on new features that don’t mean anything to your customers.
devopsy.kinsta.cloud: Doesn’t failing fast fix that?
Higbee: Failing fast could help, assuming you have metrics in place that tell you that you’re failing in a way that matters.
devopsy.kinsta.cloud: Could you please illustrate an example of isolated devs and ops that serve the given purpose better than combining them would?
Higbee: I have a history of doing projects in the software development space where we had tight collaboration with everybody that’s involved in the process. Users, stakeholders, developers, testers, managers … you name whatever role, people worked closely together. I also have a history of examples where there was no collaboration at all.
A lot of smaller projects end up in this latter bucket where you really just need one person to create a software system for a very specific purpose. They create the system, they deploy it, and then it just has to be supported at that point because it’s not going to be changed thereafter. It serves its purpose. People are happy with it. It’s probably never going to be changed ever again, so the separation there between dev and ops is perfectly acceptable and if you tried to bring together a whole team of people and synchronize them, it would just be a waste of time because the effort isn’t big enough to justify it.
Another example would be pretty much any company that has ops staff but doesn’t do their own development. They outsource their development. Sure, there are situations where a project would necessitate everybody working closely together, but I’m sure there are a lot development efforts that happen in this regard where the dev team is outside the organization so there’s going to be functional separation. They developed software, it’s deployed, and maybe it’s never changed again, so there’s really no need for some tight-knit collaboration.
devopsy.kinsta.cloud: How do recommend helping organizations produce rapid results such that they can rapidly move to a DevOps approach successfully?
Higbee: First and foremost, I don’t extol any methodology, so I’m not a DevOps consultant. I’m not an agile coach. I think it’s ludicrous when people put these fads in front of their titles. The thing that I do that makes the difference, that produces rapid results is to make sure that we have a common goal, make sure it’s crystal clear and make sure everybody understands it. It’s like hiking to the top of a mountain. Everybody knows how far along we are. They can measure their own progress. They can flag things if we’re headed in the wrong direction like down the mountain. They can always see the goal. It’s always in sight.
In another example, if you’ve ever gone to an Escape the Room Adventure, everybody is dumped into a room. It’s a group of people who oftentimes are strangers. About 10 people get dumped into a room and the goal in the duration of an hour is to get out of the room. The challenge is set up so it would be pretty difficult to get out in that hour, so if people don’t focus on that goal, then people aren’t getting out of the room.
I’m not interested in how fast we solve each of the individual puzzles, so we don’t measure those things. We just get to work on getting out of the room. That’s my approach to doing business with people and that’s how people get rapid results. Because if you have a crystal clear goal, then you can go to the last hundred years of management philosophy to find the ways you need to get to your final destination. You aren’t worried about the right way of doing things; you’re just worried about the way that works for your specific situation.
-
REP SPOTLIGHT: ITSM Academy
DevOps Institute: Tell us a little about your organization.
ITSM Academy: Since the early DevOps Days in the U.S., ITSM Academy has been involved in the DevOps community. We are proud to be the first DOI REP in The Americas. We offer DOI’s full line of training, in our open-enrollment public (virtual) classrooms as well as on-site. All instructors have completed thorough Train-the-Trainer programs and we are achieving phenomenal pass rates.
DevOps Institute: What other topics do you teach or consult on?
ITSM Academy: For the last 12+ years, ITSM Academy has offered the full ITIL catalog. These courses are all developed in house, and licensed to other organizations. Our groundbreaking Certified Process Design Engineer (CPDE) course is also developed by our in-house team.
DevOps Institute: What type of interest in DevOps are you seeing in your region?
ITSM Academy: Enterprise organizations are embracing DevOps and agile service management and attending our courses to help build sustainable programs.
DevOps Institute: How do you think DevOps contributes to the business’ value stream?
ITSM Academy: At its core, DevOps is about a shift in culture. Organizations have a tendency to focus on tools, or the automation of manual tasks. Taking a big-picture approach, starting with reviewing existing processes and being willing to re-engineer, is where the real value comes in. Organizations that are coupling DevOps training with the Certified Process Design Engineer (CPDE) course are seeing equipping their teams for success.
DevOps Institute: What topic area in DevOps excites you the most?
ITSM Academy: Improvement of the flow of work between software developers and IT operations professionals. Enriched workflows enable IT organizations to deliver greater business value by improving the ability to more quickly design, develop, deploy and operate reliable software and services.
DevOps Institute: Why should enterprises and individuals consider formal DevOps training?
ITSM Academy: DevOps is a philosophy, not a “tool” to be learned. DevOps foundation training helps teams start on the same page, with common vocabulary and goals.
-
Q&A: Full City Tech’s Higbee on Culture, Part 1
Every day, more people are hopping on the DevOps magic bus, drinking the spiked punch and singing “Kumbaya.” I imagined everyone I interviewed would offer tales of instilling this undefeatable, undeniable, brand-spanking-new rapid development culture.
It was refreshing to discover that I was mistaken. Apparently, DevOps is just another methodology for accelerating business success—one for software development.
In part one of our latest Q&A, we chat with Wes Higbee, software developer, business consultant and president of Full City Tech Co. Higbee ably defends his stance on how special DevOps and instilling a DevOps culture is or isn’t in the grand scheme of things.
devopsy.kinsta.cloud: So you say that DevOps is nothing new; that you have books collecting dust from the mid- to late-20th century describing similar organizational and management philosophies. What are some examples from those books you have collecting dust?
Higbee: DevOps is the latest reincarnation of a lot of management philosophies that have been around for a long time. There are a couple of examples to reference. Alan Weiss, author of the book, “Best Laid Plans: Turning Strategy Into Action Throughout Your Organization,” wrote about functional organization at an insurance company that employed him. They had a functional department of typists and a functional department of people that would check the typist’s work.
Underwriters sent requests to the typists to type up contracts. Typists would type up those contracts and then someone collected those for a separate group of checkers. The checkers would then check them and there was a lot of back and forth correcting errors. This led to a lot of inefficiencies.
The solution was to take the checkers and pair them up with teams of typists. So a checker could review the work of several typists. That group of people worked together, and it turned out to be much more efficient, productive and effective.
This is the heart of a cross-functional team, which is a fancy word for teamwork. This is one of the many ideas in the DevOps space, specifically taking developers and ops and putting these two groups of people together instead of having them as completely separate functional units inside the organization.
Another reference is to pretty much everything Peter Drucker wrote. Specifically with regards to the people who are talking about focusing on the big picture. This is one thing that some people in the DevOps space are getting right. They’re talking about the big picture and not making optimizations to small parts of the picture that then jeopardized the whole, so optimize the whole. This comes from the work of Peter Drucker, “Managing for Results: Economic Tasks and Risk-Taking Decisions.”
devopsy.kinsta.cloud: You say the danger is in the term DevOps itself; that as with agile, people slap a new name on what they’re already doing and think everything is better. If it’s not the terminology that needs to change to ensure a DevOps cultural transformation, then what is it?
Higbee: I can’t tell you how many times I’ve encountered DevOps where devs and ops were still siloed. If you want to be successful—and this applies to any methodology—you have to start with real problems and real opportunities, because somebody else’s best practice is your own worst practice. If your customers are happy and your company is successful, you are seeing great profit margins and great growth, why would you change anything?
Automated tests are something that people extol a lot in the DevOps space. You should have automation of your entire test suite and it should be part of your release process that’s also automated. But if you have no bugs in production, there’s no reason to go adding a bunch of tests to your release process.
However, if your users routinely experience bugs in their production environment, then it would make sense to start talking about some testing and maybe even some automated testing during your release process. But don’t start with blindly writing tests of everything in the system. Start with the specific parts that are buggy, and you might be surprised how fast you can get those parts covered with some good tests. And then once you’ve done that, stop there.