Blogging is a means of putting down your thoughts and ideas for others to read and take some sort of action. The reasons behind blogging are not really what matters much unless it is a chore or the feeling like you would rather go to the dentist and have four teeth pulled than write an article. What really matters is that you know why you are there, writing some really good content that drives people to do something, a call to action.
New bloggers struggle to get readership as much as intermediate or even long standing bloggers. Growth is a big part of your blog as lead generation and finding new people to do something not only pays the bills, it also intensifies your passion for blogging. I know that there are those out there that believe that they would have the same passion for blogging if they were not making a dime or of they were making millions. Ok, I trust you but if the readership is down, sales are down – ultimately the blog goes down. It is a cycle that we do not like to think about but encompassed in passion is drive and when there is no drive, the passion is lost and the preverbal wall is hit and little by little the blog articles decrease until one day you realize it has been a month and nothing has been posted
Bloggers alike will agree that growing your blog never stops. Sure, you may be happy with your 200 or even 2000 or so readers each day as you have probably connected with each one of them in one way or another and built an online community around your blog. But what if you could reach 25 or 50 new readers each day and you can interact with them and then their friends and their friends. If you are a follow the numbers person this is music to your ears as watching the traffic numbers increase is really something pretty to look at. How do you grow your blog, isn’t just writing great content and pushing it
out to your regulars enough?
10 Tips to Attract New Readers to Your Blog
1. Social Networking Sites
The ones that come to mind are Twitter and Facebook. You are more than likely already doing this. What about LinkedIn and industry niche platforms? LinkedIn is for job seekers right? Think again. It is a business platform where you connect and share information with others in groups and by answering questions. People will buy from people they know – and read blogs of people they know.
2. Webinars
Webinars that you tune into live almost always have a hashtag to follow on Twitter. You are exposed to others who share your interest of the webinar subject and can connect with new people by sharing thoughts about the webinar on Twitter. Connecting with people is exposing yourself to them and building a relationship.
3. Forums
Oh how I love Forums. American Express Open Forum, Third Tribe Marketing, LinkedIn Groups. Forums pack the most punch when it comes to meeting, engaging and helping others. Talking with people and helping them solve a problem is not only exposing your knowledge, willingness to help another but having your signature line have your company name, blog link and possibly an email address, is that inviting subtleness that lets them know that you have a blog and also that you are open to receive communication outside the forum.
4. Monitor Trends
Monitoring trends and getting your article up before everyone else is no easy task however, if you are on top of what is going on and keep a close eye the just when the trend starts or right after it peaks, you can get great exposure to the article and your blog. Follow Twitter trends directly from your twitter page or a freehandly tool is Trendistic. Remember, Google loves new, fresh content.
5. Read and Comment on Blogs
This is not just the a-listers. Find up and comers and read and and comment. They will be very appreciative and return the favor. They will relate to you well as you share a common thread – both up and comers and searching for ways to get new traffic. Friends read friends.
6. Read Other Commenter Blogs
Ever see the same person over and over commenting on a blog but you never really paid much mind to see if they have a blog? Find it! If they are loyal to the blog that you both are reading and commenting on, they very possibly will be loyal to those that read and comment on theirs.
7. Exceptional Content
Do you homework and write great content … content that targets keywords and also asks people do do something. The content can be the best in the world however if no -one is reading it then it is pointless especially if it does not drive it back to providing value for your business. Yes, it’s about the readers but giving them the information and them clicking off to go on to somewhere else is not providing any value to your business. Value is determined by your business strategy and what you want out of it. Are you solely looking to build your online community? Are you looking to attract new customers, new people to comment on the blog? Determine why you are blogging and then write with that in mind.
8. Interests
You have other other interests outside of work right? Well, so does everyone else. You never know who may meet that could become a customer from a shared love of futbol. It is always very easy to find fans of teams that we love and come together as one but yet when it comes to business, it seems as if we lose our ability to connect easily and freely.
9. Local Community
There is a world on the other side of the computer that is waiting for you to emerge. Going to meet-ups, networking events, sporting events is another way to meet new people and get exposure to your blog. People will be curious to see what this blog is all about especially if they are a blogger. Competition is high to see if your blog matches up to theirs.
10. Article Marketing
Ezines, GoArticles are two very popular sites that you post your articles to with the understanding that the articles may be and most likely will be republished. The articles are required to be republished “as is” with your bio paragraph as well copyright information.
There are many ways to grow your blog and increase readership. These have proven to be effective for me. The best advice to grow your blog is to first to identify why you want to grow your readership. While this may seem like it is obvious to increase sales or get new clients, the articles are not always written with this in mind. An article that is a list of how to or ways, etc. needs to have enough usable information for the reader to go and put it into motion. If it works for them, they become a loyalist. An article with an affiliate link needs to entice the reader enough that they have to click the link. Growing your blog is a long term strategy as it involves time and a whole lot of commitment. People want to connect with the author and learn more about them and know that they really care about their readers by interacting with them. We know that people love to share any mentions of themselves and who they are friends with. Be that person.
What have you done to grow your blog? What has worked and not worked for you?
Thursday, April 8, 2010
Tackling IT complexity in product design
As more products are loaded with technology, tangled IT designs can undermine product strategies. Product managers and technical specialists need a better game plan.
MARCH 2010 • Juergen Reiner and Marcus Schaper
Source: Business Technology Office
Today, it seems that just about every product contains some sort of embedded computing technology. Cars, phones, even washing machines boast interactive features that would not have been imaginable, much less affordable, a decade ago.
That such products have entered the mainstream is easy to understand (Exhibit 1). Smart phones, electronic navigational equipment, and Wi-Fi-enabled TVs offer convenience, portability, and personalization at reasonable prices. But the price of such progress is growing IT architecture1 and design complexity.
Consider the fact that in the past five years, the average number of tech-enabled engine control units in each new vehicle produced by the automotive industry has risen to 80, from 20. In the mobile-phone sector, the number of IT-based updates per year is about 40, more than twice the level back in 2000. And despite challenging economic times, the number of avionics features—from cockpit VoIP and wind sensors to the electronic flight manuals introduced in newer aircraft—has doubled in recent years. The growing demand for electronics-based product enhancements finds companies across industries struggling to keep costs in line amid fast-changing technologies and the constant pressure for product upgrades.
The problem of technical complexity
The pace of product development is creating enormous engineering and technical-development challenges. Traditional product development was driven largely by hardware considerations. When you pressed a button on an analog telephone, the button dialed one number, and that was the limit of its functionality. Today’s tech-enabled products depend on the successful integration of multiple hardware and software components—a multidimensional process. Now, a single button on a new smartphone may connect, in different ways, to a dozen distinct applications.
Software is by nature more abstract—strings of program code are pieced together in interconnected layers. The IT architecture underlying new product designs is thus far more intricate than the specifications of traditional products. In the predigital world, for instance, one vacuum cleaner operated more or less like any other. But throw in a silicon chip, and today you might have a Roomba: an intelligent robot vacuum cleaner guided by sensors and processors.
Poor product architecture
Development teams, beset by demands for customized features, may fail to realize that poor product architecture decisions upfront can have costly downstream consequences. Those teams, often led by electrical engineers, sometimes lack the specialized software-engineering skills needed to anticipate potential programming, upgrade, or reuse issues. This problem can create a vicious cycle, where poor design decisions and architecture lead to unmanageable code and greater complexity. In the auto industry, for example, a recall resulting from electronics issues cost a manufacturer close to €300 million. These design mistakes can tarnish a company’s reputation—as a high-end automaker learned after introducing new user interfaces that proved overly challenging to operate and broke down as a result of software problems.
Juggling a range of technical requirements for any single product can hinder a company’s ability to think more broadly about how certain features and functions might be leveraged across its product portfolio. This failing can force companies into a series of “one-off” applications. The Apple engineers who designed the iPod touch successfully combined new hardware (a touch screen) with better software logic (an intuitive, user-friendly interface), but others struggle to create flexible, integrated architectures. A home-electronics supplier, for instance, had to design a new user interface each time it upgraded a product—which put it at a disadvantage to competitors that took a more modular (or plug-and-play) approach to product development.
Weak linkage with business priorities
For some organizations, the bigger issue is that the technical challenges of tech-enabled products often conflict with business strategy.
Many companies have decades of experience developing mass-produced hardware-oriented products, such as televisions, radios, and home appliances, with relatively long shelf lives. Design and R&D processes have therefore been optimized around volumes and efficiency. The new era of tech-enabled products, with their niche features and faster pace of product change, requires a different set of processes and skill sets, as well as a longer learning period while organizations reshape traditional ways of doing business. The result is a significant risk of escalating costs, cycle times, and mission creep. Product managers seeking to eclipse the competition may push for next-generation design changes that stretch the limits of current technology. IT developers keen to leverage an application’s reach may overengineer a group of features.
For product strategies to be successful and sustainable, business considerations must drive technical ones. In an effort to deliver a consistently high-quality gaming experience, for instance, Nintendo deliberately kept the architecture underlying its Wii system simple, limiting the feature set in favor of rigid quality and control standards. Those traits delighted consumers and made the platform a best seller. Other companies may overlook the importance of ensuring that business audiences understand the far-from-intuitive choices that go into a product’s underlying architecture.
The abstract nature of many embedded IT systems makes functionality hard to describe. Nontechnical managers in the business units can struggle to determine which set of features and options is suitable from the standpoint of cost, ease of use, and process time. A mobile-phone company, for example, learned this lesson when unclear lines of authority led its product-development and engineering teams to argue over which of them was responsible for the features, costs, and timetables of a certain product. The confusion resulted in long lead times in completing it and a failure to offer technology matching that of the company’s rivals.
Cost management is also far more complex in the tech-enabled-product environment, where life cycles for software and hardware components often don’t align, making architectural integration difficult. The present tough economic environment exacerbates this problem. Managers are under intense pressure to bring new products to market quickly while also saving costs. In the absence of a clear development framework that brings both technological and business considerations to bear, development teams too often resort to quick fixes or “strokes of genius” rather than more sustainable solutions. To meet a launch date, for example, engineers at one company built a device with readily available, function-rich, but expensive third-party software. That helped the company meet its release target but exposed it to higher-than-expected costs.
Capturing greater value
With consumer demand for tech-enabled products continuing to grow across industries, some manufacturers are addressing these issues and optimizing electronics architectures.
Align business and engineering goals
Underlying the success of some companies in industries such as automotive and high tech is an integrated approach to designing the architectures of electronics products. In practice, that means aligning the product vision with design, the road maps of individual products with the broader electronics platform strategy, and, ultimately, the business side of product management with the engineering side. Only when companies set clear goals that demand such an alignment will customer and commercial considerations remain squarely in the center, grounding the development process and minimizing unnecessary complexity. The difference between a well-run and a poorly run development unit can vary overall productivity by a factor of ten.
A good architecture has a number of important characteristics. It is modular, allowing sections to be tagged, stored, and applied in different products. It is built on standards, providing for easier integration. It is configurable, letting one system serve many customer requirements. And it is updatable, allowing new features to be implemented without any need to discard large parts of older releases.
This list may seem straightforward. But it’s one thing to recognize a good architecture, another to build one and keep it in good shape. Setting the right goals also requires clarity about the dimensions of the task. Consider what goes into the body of a typical tech-enabled product. Hardware, plastics, resins, nuts, and bolts make up the skeletal frame. Transistors, microcircuitry, and other kinds of electronics manage the flow of information, much as tissues and veins do in living things, and software provides the neurological connections that direct and control operations. The layered architecture defines that anatomy, specifying everything from the user interface to the way the product functions to its interactions with other systems and components.
Adopt a transparent process
Companies must adopt a management process that optimizes the way these layers work together. The process involves a new form of collaboration among engineering, marketing, product design, and other product functions. Interaction helps IT- and engineering-development teams balance what the market demands in a feature set against what the business requires in costs and cycle times—all, of course, within the realm of what is possible technically. As Exhibit 2 illustrates, the best solution usually involves balancing multiple trade-offs.
Along the lines of this framework, teams from both business and IT begin by mapping their product requirements and addressing such questions as, “Who is the buying audience?” “Where is the greatest opportunity?” and “What are the right features?” Factoring in cost, budget, and other constraints, teams emphasize features likely to have the greatest impact on customer satisfaction. Those features are translated into a range of architectural components, each with its own strengths and weaknesses from a cost and performance perspective. As teams toggle through which component options make the most business and technical sense, the answers define the underlying product architecture.
With the business requirements sorted out, the teams examine their architectural design options. They may find that what they need is not yet commercially viable or that it requires too much customization for mass production. Such constraints oblige the teams to toggle between what they want and the real-world options in order to find the most suitable architecture. This iterative process forces business and IT perspectives to fuse, creating an alignment between the product’s overall strategic objective and the appropriate tech-enabled architecture.
Focus on a subset of possible architectures
One mobile-phone maker needed to create a low-cost handset for sale in emerging markets. Business requirements dictated a rugged design and a limited feature set. After a series of iterations, the engineering team presented a number of design options that emphasized electronic and mechanical components that could withstand harsh physical conditions, coupled with a small and relatively inexpensive processor. Another mobile-phone maker, with plans to compete for the iPhone demographic, had a different set of business requirements, which favored a more complex, memory-intensive architecture supporting a variety of features, despite the higher costs.
The ability to balance different design options in accordance with business strategies is the basis of an optimized tech-enabled architecture. Yet different facets of an architectural framework support different aspects of product performance—for example, those that govern customer-facing processes, define how software and hardware relate, or guide the interplay among applications (Exhibit 3). We have found that teams can simplify the process by focusing on a few specific architectural facets, weighing their relative importance to the overall set of business objectives and product capabilities.
Consider what happened at an automotive supplier struggling to improve its fuel injection system. In the company’s original siloed world, engineers built custom IT components from scratch for each product upgrade. This approach bogged down the production timetable and prevented the company from keeping pace with other market leaders.
With improvements in time to market as the main business goal, the company established a cross-functional product team that sat down to work through the iterative process described here. To stop building everything from scratch, the team agreed to create an internal library of resources to make better use of existing technologies. These embedded software systems and widely used electronic components were governed by the architecture’s capabilities (domain) layer. To streamline development and reduce component costs, the team sifted through the list of required fuel injection hardware and identified basic components that could be standardized across multiple engines. To speed up development time, engineers and product managers decided to take advantage of modular software and electronics elements. These could be plugged into a variety of different applications that made the fuel injection system work.
The resulting electronics architecture brought products to market twice as quickly as the older, more labored one. By optimizing the interior electronics, thus replacing a complex architecture with a simplified one, the company saved a few euros for every car it built. This savings added up to more than €10 million over the entire series. In addition, the platform, initially designed for four-cylinder engines, can now be used in eight-cylinder engines as well, saving the company additional costs and development time.
In another example, a power-equipment supplier was eager to get its new windmill product line up and running. But the advanced control facility for these windmills faced a sizable hurdle. The company needed to find a cost-effective way to monitor how much power the windmills were supplying to the grid. The business requirements for this feature made it clear that the best solution would be a cheap control device with an architecture that allowed it to be scaled up easily across a network of windmills.
The technical team decided that the domain-based architecture layer was the place to concentrate efforts to meet the product requirements. It met with the team from the business unit and presented three options for managing the system’s processes: a general-purpose processor, a microcontroller, and a digital signal processor. All three would measure power output, but each solution had its own costs and benefits. The technical team needed to make sure that the product managers understood the various trade-offs so that together the technical and business sides could make the optimal choice for the new tech-enabled architecture.
Weighing the three alternatives, the team found that the general-purpose processor had the advantage of being easy to install and upgrade, but the hardware supporting the processor had to be purchased separately, making it too costly. The digital signal processor offered a stripped-down operating-system architecture that was cheap to develop and could monitor basic power use, but it could not provide needed billing and reporting features. This left the microcontroller as the best option. It cost more but gave the product team the flexibility of a complete off-the-shelf solution, since all the needed hardware and software was built right in.
Building a better product-development organization
Integrated development of tech-enabled products requires an equally integrated management approach. One successful company began by creating a project steering group led by the overall product group manager and the chief technology officer, who together outlined the product platform strategy and directives. Working below this leadership level, business and engineering teams mapped out the consumer and technical requirements and then came together to discuss and prioritize the elements of the final approach. The teams shared the resulting architecture with the product group manager and the CTO to confirm that the solution would meet the company’s consumer, cost, and market delivery objectives. They also established a series of performance metrics to quantify cost and productivity gains and to further refine their ideas about where improvements could be made. This holistic procedure helped ensure that both the business and the technical team focused on the features that mattered most—those tied to the product’s overall strategic objective.
Establishing the right architecture for tech-enabled products is not a one-time effort. It’s an ongoing process that is especially important to support the product life cycle. When the search for the right architecture is elevated to a discipline followed by both engineers and the business side, companies with tech-enabled products can experience gains in productivity, quality, and costs.
--
This newsletter has been written by moderator Mustafa Emre Civelek of the group "e-Commerce Writers and Academician".
MARCH 2010 • Juergen Reiner and Marcus Schaper
Source: Business Technology Office
Today, it seems that just about every product contains some sort of embedded computing technology. Cars, phones, even washing machines boast interactive features that would not have been imaginable, much less affordable, a decade ago.
That such products have entered the mainstream is easy to understand (Exhibit 1). Smart phones, electronic navigational equipment, and Wi-Fi-enabled TVs offer convenience, portability, and personalization at reasonable prices. But the price of such progress is growing IT architecture1 and design complexity.
Consider the fact that in the past five years, the average number of tech-enabled engine control units in each new vehicle produced by the automotive industry has risen to 80, from 20. In the mobile-phone sector, the number of IT-based updates per year is about 40, more than twice the level back in 2000. And despite challenging economic times, the number of avionics features—from cockpit VoIP and wind sensors to the electronic flight manuals introduced in newer aircraft—has doubled in recent years. The growing demand for electronics-based product enhancements finds companies across industries struggling to keep costs in line amid fast-changing technologies and the constant pressure for product upgrades.
The problem of technical complexity
The pace of product development is creating enormous engineering and technical-development challenges. Traditional product development was driven largely by hardware considerations. When you pressed a button on an analog telephone, the button dialed one number, and that was the limit of its functionality. Today’s tech-enabled products depend on the successful integration of multiple hardware and software components—a multidimensional process. Now, a single button on a new smartphone may connect, in different ways, to a dozen distinct applications.
Software is by nature more abstract—strings of program code are pieced together in interconnected layers. The IT architecture underlying new product designs is thus far more intricate than the specifications of traditional products. In the predigital world, for instance, one vacuum cleaner operated more or less like any other. But throw in a silicon chip, and today you might have a Roomba: an intelligent robot vacuum cleaner guided by sensors and processors.
Poor product architecture
Development teams, beset by demands for customized features, may fail to realize that poor product architecture decisions upfront can have costly downstream consequences. Those teams, often led by electrical engineers, sometimes lack the specialized software-engineering skills needed to anticipate potential programming, upgrade, or reuse issues. This problem can create a vicious cycle, where poor design decisions and architecture lead to unmanageable code and greater complexity. In the auto industry, for example, a recall resulting from electronics issues cost a manufacturer close to €300 million. These design mistakes can tarnish a company’s reputation—as a high-end automaker learned after introducing new user interfaces that proved overly challenging to operate and broke down as a result of software problems.
Juggling a range of technical requirements for any single product can hinder a company’s ability to think more broadly about how certain features and functions might be leveraged across its product portfolio. This failing can force companies into a series of “one-off” applications. The Apple engineers who designed the iPod touch successfully combined new hardware (a touch screen) with better software logic (an intuitive, user-friendly interface), but others struggle to create flexible, integrated architectures. A home-electronics supplier, for instance, had to design a new user interface each time it upgraded a product—which put it at a disadvantage to competitors that took a more modular (or plug-and-play) approach to product development.
Weak linkage with business priorities
For some organizations, the bigger issue is that the technical challenges of tech-enabled products often conflict with business strategy.
Many companies have decades of experience developing mass-produced hardware-oriented products, such as televisions, radios, and home appliances, with relatively long shelf lives. Design and R&D processes have therefore been optimized around volumes and efficiency. The new era of tech-enabled products, with their niche features and faster pace of product change, requires a different set of processes and skill sets, as well as a longer learning period while organizations reshape traditional ways of doing business. The result is a significant risk of escalating costs, cycle times, and mission creep. Product managers seeking to eclipse the competition may push for next-generation design changes that stretch the limits of current technology. IT developers keen to leverage an application’s reach may overengineer a group of features.
For product strategies to be successful and sustainable, business considerations must drive technical ones. In an effort to deliver a consistently high-quality gaming experience, for instance, Nintendo deliberately kept the architecture underlying its Wii system simple, limiting the feature set in favor of rigid quality and control standards. Those traits delighted consumers and made the platform a best seller. Other companies may overlook the importance of ensuring that business audiences understand the far-from-intuitive choices that go into a product’s underlying architecture.
The abstract nature of many embedded IT systems makes functionality hard to describe. Nontechnical managers in the business units can struggle to determine which set of features and options is suitable from the standpoint of cost, ease of use, and process time. A mobile-phone company, for example, learned this lesson when unclear lines of authority led its product-development and engineering teams to argue over which of them was responsible for the features, costs, and timetables of a certain product. The confusion resulted in long lead times in completing it and a failure to offer technology matching that of the company’s rivals.
Cost management is also far more complex in the tech-enabled-product environment, where life cycles for software and hardware components often don’t align, making architectural integration difficult. The present tough economic environment exacerbates this problem. Managers are under intense pressure to bring new products to market quickly while also saving costs. In the absence of a clear development framework that brings both technological and business considerations to bear, development teams too often resort to quick fixes or “strokes of genius” rather than more sustainable solutions. To meet a launch date, for example, engineers at one company built a device with readily available, function-rich, but expensive third-party software. That helped the company meet its release target but exposed it to higher-than-expected costs.
Capturing greater value
With consumer demand for tech-enabled products continuing to grow across industries, some manufacturers are addressing these issues and optimizing electronics architectures.
Align business and engineering goals
Underlying the success of some companies in industries such as automotive and high tech is an integrated approach to designing the architectures of electronics products. In practice, that means aligning the product vision with design, the road maps of individual products with the broader electronics platform strategy, and, ultimately, the business side of product management with the engineering side. Only when companies set clear goals that demand such an alignment will customer and commercial considerations remain squarely in the center, grounding the development process and minimizing unnecessary complexity. The difference between a well-run and a poorly run development unit can vary overall productivity by a factor of ten.
A good architecture has a number of important characteristics. It is modular, allowing sections to be tagged, stored, and applied in different products. It is built on standards, providing for easier integration. It is configurable, letting one system serve many customer requirements. And it is updatable, allowing new features to be implemented without any need to discard large parts of older releases.
This list may seem straightforward. But it’s one thing to recognize a good architecture, another to build one and keep it in good shape. Setting the right goals also requires clarity about the dimensions of the task. Consider what goes into the body of a typical tech-enabled product. Hardware, plastics, resins, nuts, and bolts make up the skeletal frame. Transistors, microcircuitry, and other kinds of electronics manage the flow of information, much as tissues and veins do in living things, and software provides the neurological connections that direct and control operations. The layered architecture defines that anatomy, specifying everything from the user interface to the way the product functions to its interactions with other systems and components.
Adopt a transparent process
Companies must adopt a management process that optimizes the way these layers work together. The process involves a new form of collaboration among engineering, marketing, product design, and other product functions. Interaction helps IT- and engineering-development teams balance what the market demands in a feature set against what the business requires in costs and cycle times—all, of course, within the realm of what is possible technically. As Exhibit 2 illustrates, the best solution usually involves balancing multiple trade-offs.
Along the lines of this framework, teams from both business and IT begin by mapping their product requirements and addressing such questions as, “Who is the buying audience?” “Where is the greatest opportunity?” and “What are the right features?” Factoring in cost, budget, and other constraints, teams emphasize features likely to have the greatest impact on customer satisfaction. Those features are translated into a range of architectural components, each with its own strengths and weaknesses from a cost and performance perspective. As teams toggle through which component options make the most business and technical sense, the answers define the underlying product architecture.
With the business requirements sorted out, the teams examine their architectural design options. They may find that what they need is not yet commercially viable or that it requires too much customization for mass production. Such constraints oblige the teams to toggle between what they want and the real-world options in order to find the most suitable architecture. This iterative process forces business and IT perspectives to fuse, creating an alignment between the product’s overall strategic objective and the appropriate tech-enabled architecture.
Focus on a subset of possible architectures
One mobile-phone maker needed to create a low-cost handset for sale in emerging markets. Business requirements dictated a rugged design and a limited feature set. After a series of iterations, the engineering team presented a number of design options that emphasized electronic and mechanical components that could withstand harsh physical conditions, coupled with a small and relatively inexpensive processor. Another mobile-phone maker, with plans to compete for the iPhone demographic, had a different set of business requirements, which favored a more complex, memory-intensive architecture supporting a variety of features, despite the higher costs.
The ability to balance different design options in accordance with business strategies is the basis of an optimized tech-enabled architecture. Yet different facets of an architectural framework support different aspects of product performance—for example, those that govern customer-facing processes, define how software and hardware relate, or guide the interplay among applications (Exhibit 3). We have found that teams can simplify the process by focusing on a few specific architectural facets, weighing their relative importance to the overall set of business objectives and product capabilities.
Consider what happened at an automotive supplier struggling to improve its fuel injection system. In the company’s original siloed world, engineers built custom IT components from scratch for each product upgrade. This approach bogged down the production timetable and prevented the company from keeping pace with other market leaders.
With improvements in time to market as the main business goal, the company established a cross-functional product team that sat down to work through the iterative process described here. To stop building everything from scratch, the team agreed to create an internal library of resources to make better use of existing technologies. These embedded software systems and widely used electronic components were governed by the architecture’s capabilities (domain) layer. To streamline development and reduce component costs, the team sifted through the list of required fuel injection hardware and identified basic components that could be standardized across multiple engines. To speed up development time, engineers and product managers decided to take advantage of modular software and electronics elements. These could be plugged into a variety of different applications that made the fuel injection system work.
The resulting electronics architecture brought products to market twice as quickly as the older, more labored one. By optimizing the interior electronics, thus replacing a complex architecture with a simplified one, the company saved a few euros for every car it built. This savings added up to more than €10 million over the entire series. In addition, the platform, initially designed for four-cylinder engines, can now be used in eight-cylinder engines as well, saving the company additional costs and development time.
In another example, a power-equipment supplier was eager to get its new windmill product line up and running. But the advanced control facility for these windmills faced a sizable hurdle. The company needed to find a cost-effective way to monitor how much power the windmills were supplying to the grid. The business requirements for this feature made it clear that the best solution would be a cheap control device with an architecture that allowed it to be scaled up easily across a network of windmills.
The technical team decided that the domain-based architecture layer was the place to concentrate efforts to meet the product requirements. It met with the team from the business unit and presented three options for managing the system’s processes: a general-purpose processor, a microcontroller, and a digital signal processor. All three would measure power output, but each solution had its own costs and benefits. The technical team needed to make sure that the product managers understood the various trade-offs so that together the technical and business sides could make the optimal choice for the new tech-enabled architecture.
Weighing the three alternatives, the team found that the general-purpose processor had the advantage of being easy to install and upgrade, but the hardware supporting the processor had to be purchased separately, making it too costly. The digital signal processor offered a stripped-down operating-system architecture that was cheap to develop and could monitor basic power use, but it could not provide needed billing and reporting features. This left the microcontroller as the best option. It cost more but gave the product team the flexibility of a complete off-the-shelf solution, since all the needed hardware and software was built right in.
Building a better product-development organization
Integrated development of tech-enabled products requires an equally integrated management approach. One successful company began by creating a project steering group led by the overall product group manager and the chief technology officer, who together outlined the product platform strategy and directives. Working below this leadership level, business and engineering teams mapped out the consumer and technical requirements and then came together to discuss and prioritize the elements of the final approach. The teams shared the resulting architecture with the product group manager and the CTO to confirm that the solution would meet the company’s consumer, cost, and market delivery objectives. They also established a series of performance metrics to quantify cost and productivity gains and to further refine their ideas about where improvements could be made. This holistic procedure helped ensure that both the business and the technical team focused on the features that mattered most—those tied to the product’s overall strategic objective.
Establishing the right architecture for tech-enabled products is not a one-time effort. It’s an ongoing process that is especially important to support the product life cycle. When the search for the right architecture is elevated to a discipline followed by both engineers and the business side, companies with tech-enabled products can experience gains in productivity, quality, and costs.
--
This newsletter has been written by moderator Mustafa Emre Civelek of the group "e-Commerce Writers and Academician".
make-it-green-cloud-computing-and-its-contribution-to-climate-change
Powering the cloud - how much will it take?
How much electricity or associated greenhouse gas pollution is
currently produced or will be generated to power a much bigger cloud
in 10 years? The answer is far from clear, given the rapid growth, and
that many major cloud brands refuse to disclose their energy footprint.
The Smart 2020 analysis forecast that the global carbon footprint of the
main components of cloud-based computing - data centres and the
telecommunications network - would see their emissions grow, on
average, 7%and 5%respectively each year between 2002-2020.
Underlying this analysis is the number of data centre servers growing
on average 9%each year during this period.
Using the global analysis and forecast of the overall ICT emissions
footprint in the Smart 2020 Report as a foundation, the following
reports seeks to shine a fresh light on the electricity demand of the
global cloud, highlighting the scale of the potential demand and
importance of where and what sources of electricity are being used to
power Facebook, Gmail, and other cloud-based computing platforms.
The first of the two adjustments were made to the analysis used in the
Smart 2020 Report to disaggregate the projections for growth in the
main components of cloud based computing, and place in context of
electricity demand and renewable energy supply. The third adjustment
incorporates some bottom up analysis of energy demand from data
centres in the US, and the scale impact on the size of the overall
electricity demand if more accurate estimation of the energy demand
and GHG emissions associated with large data centres.To make the
data of the report more accessible as an instrument to evaluate the
projected impact of the cloud on electricity demand and their
relationship to energy policies, the Smart 2020 analysis has been de-
aggregated to show overall electricity consumption as outlined below.
[...]
<<
PDF, 1MB
Powering the cloud - how much will it take?
How much electricity or associated greenhouse gas pollution is
currently produced or will be generated to power a much bigger cloud
in 10 years? The answer is far from clear, given the rapid growth, and
that many major cloud brands refuse to disclose their energy footprint.
The Smart 2020 analysis forecast that the global carbon footprint of the
main components of cloud-based computing - data centres and the
telecommunications network - would see their emissions grow, on
average, 7%and 5%respectively each year between 2002-2020.
Underlying this analysis is the number of data centre servers growing
on average 9%each year during this period.
Using the global analysis and forecast of the overall ICT emissions
footprint in the Smart 2020 Report as a foundation, the following
reports seeks to shine a fresh light on the electricity demand of the
global cloud, highlighting the scale of the potential demand and
importance of where and what sources of electricity are being used to
power Facebook, Gmail, and other cloud-based computing platforms.
The first of the two adjustments were made to the analysis used in the
Smart 2020 Report to disaggregate the projections for growth in the
main components of cloud based computing, and place in context of
electricity demand and renewable energy supply. The third adjustment
incorporates some bottom up analysis of energy demand from data
centres in the US, and the scale impact on the size of the overall
electricity demand if more accurate estimation of the energy demand
and GHG emissions associated with large data centres.To make the
data of the report more accessible as an instrument to evaluate the
projected impact of the cloud on electricity demand and their
relationship to energy policies, the Smart 2020 analysis has been de-
aggregated to show overall electricity consumption as outlined below.
[...]
<<
PDF, 1MB
http://www.greenpeace.org/raw/content/international/press/reports/make-it-green-cloud-computing.pdf
How much electricity or associated greenhouse gas pollution is
currently produced or will be generated to power a much bigger cloud
in 10 years? The answer is far from clear, given the rapid growth, and
that many major cloud brands refuse to disclose their energy footprint.
The Smart 2020 analysis forecast that the global carbon footprint of the
main components of cloud-based computing - data centres and the
telecommunications network - would see their emissions grow, on
average, 7%and 5%respectively each year between 2002-2020.
Underlying this analysis is the number of data centre servers growing
on average 9%each year during this period.
Using the global analysis and forecast of the overall ICT emissions
footprint in the Smart 2020 Report as a foundation, the following
reports seeks to shine a fresh light on the electricity demand of the
global cloud, highlighting the scale of the potential demand and
importance of where and what sources of electricity are being used to
power Facebook, Gmail, and other cloud-based computing platforms.
The first of the two adjustments were made to the analysis used in the
Smart 2020 Report to disaggregate the projections for growth in the
main components of cloud based computing, and place in context of
electricity demand and renewable energy supply. The third adjustment
incorporates some bottom up analysis of energy demand from data
centres in the US, and the scale impact on the size of the overall
electricity demand if more accurate estimation of the energy demand
and GHG emissions associated with large data centres.To make the
data of the report more accessible as an instrument to evaluate the
projected impact of the cloud on electricity demand and their
relationship to energy policies, the Smart 2020 analysis has been de-
aggregated to show overall electricity consumption as outlined below.
[...]
<<
PDF, 1MB
Powering the cloud - how much will it take?
How much electricity or associated greenhouse gas pollution is
currently produced or will be generated to power a much bigger cloud
in 10 years? The answer is far from clear, given the rapid growth, and
that many major cloud brands refuse to disclose their energy footprint.
The Smart 2020 analysis forecast that the global carbon footprint of the
main components of cloud-based computing - data centres and the
telecommunications network - would see their emissions grow, on
average, 7%and 5%respectively each year between 2002-2020.
Underlying this analysis is the number of data centre servers growing
on average 9%each year during this period.
Using the global analysis and forecast of the overall ICT emissions
footprint in the Smart 2020 Report as a foundation, the following
reports seeks to shine a fresh light on the electricity demand of the
global cloud, highlighting the scale of the potential demand and
importance of where and what sources of electricity are being used to
power Facebook, Gmail, and other cloud-based computing platforms.
The first of the two adjustments were made to the analysis used in the
Smart 2020 Report to disaggregate the projections for growth in the
main components of cloud based computing, and place in context of
electricity demand and renewable energy supply. The third adjustment
incorporates some bottom up analysis of energy demand from data
centres in the US, and the scale impact on the size of the overall
electricity demand if more accurate estimation of the energy demand
and GHG emissions associated with large data centres.To make the
data of the report more accessible as an instrument to evaluate the
projected impact of the cloud on electricity demand and their
relationship to energy policies, the Smart 2020 analysis has been de-
aggregated to show overall electricity consumption as outlined below.
[...]
<<
PDF, 1MB
http://www.greenpeace.org/raw/content/international/press/reports/make-it-green-cloud-computing.pdf
Subscribe to:
Comments (Atom)